03 설계 원칙 (1)

SOLID 원칙

SOLID 원칙은 함수와 데이터 구조를 클래스로 배치하는 방법, 그리고 이들 클래스를 서로 결합하는 방법을 설명해준다.

• SRP : 단일 책임 원칙 Single Responsibility Principle 
  각 소프트웨어 모듈은 변경의 이유가 단 하나여야만 한다. 
• OCP : 개방-폐쇄 원칙 Open-Closed Principle
  기존 코드를 수정하기보다는 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야만 소프트웨어 시스템을 쉽게 변경할 수 있다.
• LSP : 리스코프 치환원칙 Liskov Substitution Principle
  상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성요소는 반드시 서로 치환 가능해야 한다.
• ISP : 인터페이스 분리 원칙 Interface Segregation Princple
  소프트웨어 설계자는 사용하지 않는 것에 의존하지 않아야 한다.
• DIP 의존성 역전 원칙 Dependency Inversion Principle
  고수준 정책을 구현하는 코드는 저수준 세부수행을 구현하는 코드에 의존해서는 안된다. 정책은 세부사항이 의존해야 한다. 

---

7장. SRP : 단일 책임 원칙

단일 책임 원칙은 모든 모듈이 단 하나의 일만 해야 한다는 의미가 아니다.

그것은 함수의 원칙이다(함수는 반드시 하나의 일만 해야 한다). 

 

단일책임 원칙은 하나의 모듈은 하나의 액터(사용자, 이해관계자)에 대해서만 책임져야 한다는 의미이다.

 

단일책임 원칙을 이해하기위해 이 원칙을 위반하는 징후들을 살펴보자.

 

징후1 : 우발적 중복

하나의 클래스에 서로 다른 액터(회계팀, 인사팀, DBA)의 기능을 정의하고 메서드를 공유할 경우,

회계팀의 요청사항에 의해 메서드를 수정했는데 인사팀의 기능까지 영향을 미칠 수 있다.

 

징후2 : 병합

많은 사람이 서로 다른 목적으로 동일한 소스파일을 변경하는 경우, 변경사항은 충돌하고 결과적으로 병합이 발생한다.

 

해결책

1. 데이터와 메서드를 분리하고 클래스를 인터페이스화한다.

2. 인터페이스를 간단하게 사용하기위해 퍼사드(facade) 패턴을 사용한다.

3. 가장 중요한 메서드는 기존 클래스에 유지하되, 덜 중요한 나머지 메서드는 퍼사드로 사용한다. 

단일 책임 원칙은 메서드와 클래스 수준의 원칙이다.

이를 상위 수준으로 확장하면 컴포넌트  수준에서는 공통 폐쇄 원칙이 되고,

아키텍처 수준에서는 아키텍처 경계의 생성을 책임지는 변경의 축이 된다.

 

---

8장. OCP : 개방-폐쇄 원칙

소프트웨어 개체는 확장에는 열려있어야 하고, 변경에는 닫혀 있어야 한다.

소프트웨어 개체의 행위는 확장할 수 있어야하지만, 이때 개체를 변경해서는 안된다는 뜻이다.

 

변경되는 코드를 최소화하면서 기능을 추가하려면 어떻게 해야할까?

서로 다른 목적으로 변경되는 요소를 적절하게 분리하고(단일 책임 원칙), 요소 사이의 의존성을 체계화(의존성 역전 원칙)해야 한다.

 

처리 과정을 클래스 단위로 분할하고, 이들 클래스를 컴포넌트 단위로 구분해야 한다.

그리고 컴포넌트들 간의 의존 관계는 변경을 보호하려는 방향으로 이루어져야 한다.

 

A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트를 보호하려면 반드시 A 컴포넌트가 B 컴포넌트에 의존해야 한다.

위 그림에서 controller는 presenter의 변경으로부터 보호되고, presenter는 view로부터 보호된다.

 

Interactor는 가장 높은 수준의 정책인 업무 규칙을 포함하고 있으므로, 어떤 변경도 영향을 주지 않는 위치에 있어야 한다.

반면, View는 가장 낮은 수준의 개념 중 하나로 거의 보호를 받지 못하는 위치에 있다.

 

아키텍트는 기능이 어떻게, 왜, 언제 발생하는지에 따라서 기능을 분리하고, 분리한 기능을 컴포넌트 계층구조로 조직화한다.

컴터넌트 계층구조를 조직화하면 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있다.