SOLID 원칙 쉽게 이해하고 적용하기SOLID Principles for Better Software Design
📅
🚀
패턴 지식의 계층 구조 (Hierarchy of Pattern Knowledge) 🔗
- 디자인 패턴 (Design Patterns)
- 전략 패턴 (Strategy Pattern) 알고리즘의 집합을 정의하고, 각각을 캡슐화하며 이들을 상호 교체가 가능하게 만든다. 전략을 사용하는 클라이언트는 전략을 사용하는 동안 전략을 변경할 수 있다.
- 객체 지향 원칙 (Object-Oriented Principles)
- 변하는 것을 캡슐화함
- 상속보다는 구성을 선호함
- 구현이 아닌 인터페이스에 맞춰서 프로그래밍함
- 객체 지향 기본 (Object-Oriented Basics)
- 클래스와 객체
- 상속
- 다형성
- 캡슐화
- 추상화
🚀
디자인 악취 (Design Smells) 🔗
나쁜 디자인의 다양한 징후와 증상
| 이름 | 증상 |
|---|---|
| 경직성 (Rigidity) | 시스템이 변경하기 어렵다. 한 가지를 변경할 때마다 끝없는 연속적인 변경이 필요하다. |
| 취약성 (Fragility) | 시스템의 한 부분을 변경하면 다른 여러 관련 없는 부분이 깨진다. |
| 부동성 (Immobility) | 다른 시스템에서 재사용할 수 있도록 시스템을 구성 요소로 분리하기 어렵다. |
| 점착성 (Viscosity) | 설계에 맞는 코드를 추가하는 것보다 임시방편으로 코드를 추가하는 것이 더 쉬운 경우 점착성이 높다 |
| 불필요한 복잡성 (Needless Complexity) | 현재는 필요하지 않지만 언젠가는 유용할 수 있는 복잡한 코드 구조가 많다. |
| 불필요한 반복 (Needless Repetition) | 코드를 마치 '복사 및 붙여넣기'를 사용하여 두 명의 프로그래머가 작성한 것처럼 보인다. |
| 불투명성 (Opacity) | 원 작성자의 의도를 이해하는 것이 표현의 복잡성과 관련된 특정 어려움을 수반한다. |
🚀
의존성 관리 (Dependency Management) 🔗
디자인 악취는
관리되지 않은 의존성
으로 인해 발생한다.
관리되지 않은 의존성
- 얽힌 결합 덩어리(스파게티 코드)
객체 지향 언어는 의존성을 관리하기 위한 다양한 기능을 제공한다.
- 인터페이스: 객체 간의 의존성을 줄이기 위한 계약
- 다형성: 모듈이 메서드를 동적으로 호출할 수 있게 함
🚀
객체 지향 설계 원칙 (Object-Oriented Design Principles) 🔗
- SOLID 원칙 by Robert C. Martin
- GRASP 원칙 by Craig Larman
- 구현이 아닌 인터페이스 대상 프로그래밍 (Interface-Oriented Programming)
- 클래스 상속보다는 객체 조합 선호
- 변하는 것을 캡슐화
🚀
SOLID 원칙 🔗
- 단일 책임 원칙 (Single Responsibility Principle)SRP
- 개방-폐쇄 원칙 (Open-Closed Principle)OCP
- 리스코프 치환 원칙 (Liskov Substitution Principle)LSP
- 인터페이스 분리 원칙 (Interface Segregation Principle)ISP
- 의존성 역전 원칙 (Dependency Inversion Principle)DIP