8장 OCP: 개방-폐쇄 원칙
개방-폐쇄 원칙은 확장에는 열려 있어야하고, 변경에는 닫혀 있어야 한다.
사고실험
소프트웨어 아키텍처가 훌륭하다면, 변경되는 코드의 양이 가능한 한 최소화 될 것이다. 이상적인 변경량은 0 이다.
변경되는 요소를 적절하게 분리하고 (SRP), 이들 사이의 의존성을 체계화하면(DIP) 변경량을 최소화 할 수 있다.
처리과정을 클래스 단위로 분할하고, 이 클래스를 컴포넌트 단위로 분리해야 한다.
- : 인터페이스, : 데이터 구조
- 화살표가 열려있다면 사용관계, 화살표가 닫혀있다면 구현 또는 상속 관계이다.
여기서 FinancialDataMapper은 구현관계를 통해, FinancialDataGateway를 알고 있지만, FinancialDataGateway는 FinancialDataMapper를 알지 못한다.
그리고 컴포넌트 관계는 모두 단방향으로 이루어져 있다.
(화살표는 변경으로부터 보호하려는 컴포넌트를 향하도록 그려진다.)
- Presenter에서 발생한 변경으로 부터 Controller을 보호하고자한다.
- View에서 발생한 변경으로 부터 Presenter을 보호하고자한다.
- Interactor은 모든 것에서 발생한 변경으로부터 보호하고자 한다.
Interactor가 가장 높은 수준의 정책을 포함하기 때문에, 이렇게 구성되어 있다.
아키텍트는 기능이 왜, 어떻게, 언제 발생하는지에 따라 기능을 분리하고, 분리한 기능을 컴포넌트의 계층구조로 조직화 한다.
→ 저수준의 컴포넌트에서 발생한 변경으로 부터 고수준 컴포넌트를 보호할 수 있다.
방향성 제어
FinancialDataGateway 인터페이스는 FinancialReportGenerator와 FinancialDataMapper 사이에 위치하는데, 이는 의존성 역전시키기 위해서 이다.
(FinancialReport 인터페이스와 2개의 view 인터페이스도 같은 목적을 가진다)
정보 은닉
FinancialReportRequester는 방향성 제어와는 다른 목적을 가진다 → 정보은닉의 목적
FinancialReportController가 Ineractor 내부에 대해 너무 많이 알지 못하도록 막기 위해서 이다.
이게 없었다면, Controller은 FinancialEntities에 대해 추이 종속성을 가지게 된다.
Controller에서 발생한 변경으로 부터 Interactor을 보호하는 일이 우선순위 지만, 반대로 Interactor에서 발생한 변경으로 부터 Controller또한 보호되기 바라기 때문에, Interactor의 내부를 은닉한다.
결론
OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는데에 있다.
따라서, 시스템을 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어져야한다.
