[디자인패턴] SOLID 원칙

Design Smells

Name	Symptoms
Rigidity (경직성)	The system is hard to change, because every time you change one thing, you have to change something else in a never ending succession of changes.
Fragility (취약성)	A change to one part of the system causes it to break in many other, completely unrelated parts.
Immobility (부동성)	It is hard to disentangle the system into components that can be reused in other systems.
Viscosity (점착성)	If it is easier to add a hack than it is to add code that fits into the design, then the system has high viscosity.
Needless Complexity (불필요한 복잡성)	There are lots of very clever code structures that aren't actually necessary right now, but could be very useful one day
Needless Repetition (불필요한 반복)	The code looks like it was written by two programmers named Cut and Paste.
Opacity (불투명성)	Elucidation of the originator's intent presents certain difficulties related to convolution of expression

R.C. Martin's Software Design Principles: SOLID 원칙

• Single-Responsibility Principle (SRP) : 단일 책임 원칙
• Open-Closed Principle (OCP) : 개방 폐쇄 원칙
• Liskov Substitution Principle (LSP) : 리스코프 치환 원칙
• Interface Segregation Principle (ISP) : 인터페이스 분리 원칙
• Dependency Inversion Principle (DIP) : 의존관게 역전 원칙

1. Single Responsibility Principle (SRP) : 단일 책임 원칙

A class should have one, and only one, reason to change

모든 클래스는 하나의 책임만 가지며, 클래스는 그 책임을 완전히 캡슐화해야 합니다. 

로버트 마틴은 책임을 변경하려는 이유로 정의합니다. 클래스는 변경하려는 단 하나의 이유만을 가져야 한다고 주장합니다.

한 클래스가 여러 개의 책임을 갖고 있다면, 클래스를 분리하여 하나의 책임만을 가져야 합니다. 왜냐하면, 한 책임이 바뀌면, 다른 책임에도 영향이 갈 수 있기 때문입니다. 유지보수 하는 시간이 더욱 길어지게 되는거죠.

2. Open Closed Principle (OCP) : 개방 폐쇄 원칙

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.

( You should be able to extend a class's behavior, without modifying it. )

개방 폐쇄 원칙의 두 가지 속성은 다음과 같습니다.

확장에 대해 열려 있다.

애플리케이션의 요구 사항이 변경될 때, 이 변경에 맞게 새로운 동작을 추가해 모듈을 확장할 수 있습니다.

모듈이 하는 일을 변경할 수 있습니다.

수정에 대해 닫혀 있다.

기존 모듈의 소스 코드나 바이너리 코드를 수정하지 않아도 모듈의 기능을 확장하거나 변경할 수 있어야 합니다.

3. Liskov Substitution Principle (LSP) : 리스코프 치환 원칙

Subtypes must be substitutable for their base types.

자료형 S가 자료형 T의 하위형이라면, 프로그램의 속성 변경 없이 자료형 T의 객체를 자료형 S의 객체로 교체(치환)할 수 있어야 합니다. 

4. Interface Segregation Principle (ISP) : 인터페이스 분리 원칙

Client should not be forced to depend on methods they do not use

클라이언트가 자신이 이용하지 않는 메소드에 의존하지 않아야 합니다. 만약 인터페이스가 맡고 있는 기능이 크다면, 구체적이고 작게 분리시킴으로써 클라이언트들이 꼭 필요한 메소드들만 이용할 수 있게 합니다.

내부 의존성을 낮춰 리팩토링과 수정, 배포를 수월하게 해줍니다.

5. Dependency Inversion Principle (DIP) : 의존관계 역전 원칙

High-level modules should not depend on low-level modules. Both should depend on abstractions.

상위 계층이 하위 계층에 의존하는 관계를 역전(반전)시킴으로써 상위 계층이 하위 계층의 구현으로부터 독립되게 할 수 있습니다. 상위 계층과 하위 계층 모두 추상화에 의존해야 합니다. 추상화는 세부 사항에 의존해서는 안됩니다. 반대로 세부 사항이 추상화에 의존해야 합니다.