SOLID - 코드로 이해하기

1. 단일책임원칙 Single Responsibility Principle
 
Invoice 클래스는 계산서인데, 세금 계산(calculateTax), 계산서 출력(printInvoice), 데이터베이스 저장(saveToDatabase)를 왜 하냐...
다 분리해서 따로 두어야 응집력이 올라간다.

 
그래서 아래와 같이 4개의 클래스로 분리한다. 각 클래스는 자신의 책임만을 다한다.

 
 
 
2. 개방 폐쇄 원칙 Open Close Principle
 
클라이언트가 접근하는 부분에 대해서 수정에는 닫혀 있고 확장에는 열려 있어야 한다. 인터페이스 분리가 되어야 하는데, 아래의 코드는 Sorter 클래스에 어떤 소팅 알고리즘을 쓸 것인지에 대한 구현까지 다 들어가 있다. 확장하려면, 다 뜯어 고쳐야 한다. 문제다.

 
이렇게 SortStrategy라는 인터페이스를 두고, BubbleSort, QuickSort, MergeSort는 SortStrategy를 implement 하면 된다. 그러면 SortStrategy를 구현하는 소팅 알고리즘이 변경되거나 늘어나도, Sorter는 바뀌지 않는다.

 
 
 
3. 리스코프 대체 원칙 Liskov Substitution Principle
 
하위 클래스가 상위 클래스를 대체할 수 있어야 한다. 상위 클래스를 상속 받아서 구현하는데, 상위 클래스에 있는 메서드를 구현하지 못해서 서 불필요한 Exception을 날리는 것을 방지하자.
 
Bird 클래스 내부에 fly()메서드를 둬서, 날지 못하는 Ostrich는 불필요한 예외를 날리게 된다. fly 행동은 인터페이스로 빼고, Bird에는 새의 공통 속성만 두자.

 
Bird 인터페이스를 상속 받은 FlyingBird 인터페이스에만 fly()메서드가 있다. 날 수 있는 새는 FlyingBird를 구현하면 되고, 날지 못하는 새는 Bird를 구현하자.

 
 
4. 인터페이스 분리 원칙 Interface Segregation Principle
 
비만 인터페이스를 방지하자. 인터페이스에 필요 없는게 들어가면, 쓸데 없이 exception을 날려야 한다.
Worker 인터페이스 work()와 eat()이 있다. Robot은 먹지 못하므로 eat()을 구현할 수 없다. exception을 날린다. 이렇게 하지 말고, work(), eat()을 따로따로 인터페이스로 두자.

 
아래와 같이 Workable, Eatable 인터페이스를 나눴다. 이제 HumanWorker 클래스와 RobotWorker 클래스는 자기한테 필요한 인터페이스만 구현하면 되는 것이다. 

 
 
5. 의존 관계역전 원리 Dependency Inversion Principle
 
고수준 모듈은 저수준 모듈에 의존하면 안된다. 둘다 추상(인터페이스)에 의존해야한다. 그래서 그 사이에 인터페이스를 하나 두는 전략이다. Computer 클래스가 Keyboard 클래스를 직접 생성하고 있다. 결합이 강하다... 왜냐하면 키보드가 바뀐다면 컴퓨터도 바뀌어야 하기 때문이다. 둘다 추상 클래스에 의존하도록 해주려면 어떻게 해야할까?

 
아래와 같이 인터페이스에 의존하도록 했다. Computer는 바뀌지 않아도 된다.