[디자인패턴] SOLID Principles

R.C. Martin’s Software design principles (SOLID)

원칙		설명
SRP	The Single-Responsibility Principle	A class should have one, and only one, reason to change 클래스는 하나의 (오직 하나의) 변경의 이유를 가져야 한다 -> 변경에 영향을 적게 받아야 함 - Responsibility (책임)   . a contract or obligation of a class   . reason to change (변경의 이유)  - Separate coupled responsibilites into separate classes   결합된 책임들은 분리된 클래스로 분리하라
OCP	The Open-Closed Principle	Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification Software entities들은 확장을 위해 Open되어야 하고 수정을 위해서는 Closed 되어야 함 - 기존의 코드를 변경하지 않고 (Closed) 기능을 수정하거나 추가할 수 있도록 (Open)    설계 되어야 함    . Open for extension    . Closed for modification - Abstraction is the Key - 변화가 발생할 것에 대한 전략이 필요함     . 변화가 확실한 경우에만 추상화 적용     . 처음에는 변화지 않을것이라 생각하고 개발 -> 변화가 발생하면 그때 추상화 적용
LSP	The Liskov Substitution Principle	Subtypes must be substitutable for their base types Subtype은 base type을 대체할 수 있다 - Subtyping : interface inheritance (IS_A relationship) - Implementation Inheritance  * Inheritance를 사용할 때에는 항상 조심해야 함    . 객체간의 결합 등을 통해서 재사용에 활용 (Composition 등)
ISP	The Interface Segregation Principle	Client should not be forced to depend on methods they do not use 클라이언트는 그들이 사용하지 않는 method에 대한 dependency를 가지지 않아야 함 - Interface를 너무 크게 만들면 내가 사용하지 않는 기능을 사용하게 됨   -> Interface를 기능별로 나눠서 만들어 줘야함
DIP	The Dependency Inversion Principle	High-level modules should not depend on low-level modules. Both should depend on abstractions High-level modules은 low-level modules에 의존적이지 않아야 하며, 둘 다는 추상화에 의존적이어야 함 - High-level resource (= Interface and abstract classes)    Low-level resource (=Concrete classes) - Dependency의 방향 뿐만 아니라 ownership의 방향도 기존의 구조적 설계방식과 비교해서    역전됨 - Interface와 Implementation을 분리

Design principles 은

- Dependency 관리를 도와줌

- 유지보수성(maintainability), 유연성(flexibility), 견고성(robustness) 및 재사용성(reusability)이 향상됨

- 추상화가 중요함