SOLID 원칙의 5대 기둥

카테고리

프로그래밍/소프트웨어 개발

서브카테고리

개발 툴

대상자

• 초보자 및 중급 개발자에게 적합한 설계 패턴
• 난이도: 중간 (실무 적용 중심)

핵심 요약

• SRP (Single Responsibility Principle): 클래스는 하나의 책임만 가짐. 예: class UserManager와 class EmailService 분리
• OCP (Open/Closed Principle): 확장은 허용하고 수정은 금지. 예: RegularDiscount와 VIPDiscount로 기능 확장
• LSP (Liskov Substitution Principle): 하위 클래스가 상위 클래스와 동일한 동작을 보장. 예: Penguin은 fly() 대신 swim() 메서드 사용
• ISP (Interface Segregation Principle): 사용하지 않는 메서드 강요 금지. 예: Printer, Scanner 인터페이스 분리
• DIP (Dependency Inversion Principle): 추상화에 의존. 예: DataService는 Database 추상화에 의존

섹션별 세부 요약

1. SRP (단일 책임 원칙)

• 클래스는 하나의 기능만 처리해야 한다.
• 예: UserManager는 사용자 관리만, EmailService는 이메일 전송만 담당.
• 코드 분리로 테스트 및 유지보수가 용이해진다.

2. OCP (개방-폐쇄 원칙)

• 기능 확장은 새로운 클래스 추가로, 기존 코드 수정 없이 수행.
• 예: Discount 클래스 대신 RegularDiscount, VIPDiscount로 확장.
• 기존 테스트 코드가 영향을 받지 않도록 설계.

3. LSP (리스코프 치환 원칙)

• 하위 클래스는 상위 클래스의 동작을 대체할 수 있어야 한다.
• 예: Penguin은 Bird의 fly() 대신 swim() 메서드로 동작.
• 잘못된 설계는 예상치 못한 오류로 이어질 수 있음.

4. ISP (인터페이스 분리 원칙)

• 클라이언트는 사용하지 않는 메서드를 강요받지 않도록 인터페이스를 분리.
• 예: Machine 대신 Printer, Scanner, Fax 인터페이스로 분리.
• 불필요한 메서드 구현을 피해 코드 간결성 향상.

5. DIP (의존성 역전 원칙)

• 추상화에 의존하고 구체적 구현에 의존하지 않도록 설계.
• 예: DataService는 Database 추상화에 의존, MySQLDatabase는 구현체.
• 테스트 시 모킹 가능, 유연성과 확장성 향상.

결론

• SOLID 원칙은 설계의 유연성과 확장성을 높이는 핵심 지침
• 각 원칙을 실무에서 적용할 때는 구체적인 예시 코드를 참고해 설계 패턴을 정리해야 함
• SRP는 모듈 분리, OCP는 확장성, DIP는 테스트 용이성을 강조하며, 지속적인 적용이 설계 능력 향상에 기여함