8장 OCP: Open-Closed Principle 개방-폐쇄 원칙

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

개체의 행위는 확장할 수 있어야 하지만, 개체를 변경해서는 안된다.

 

기존 코드를 수정하기 보다는 새로운 코드를 추가하는 방식으로 시스템의 행위를 변경할 수 있도록 설계해야 소프트웨어 시스템을 쉽게 변경할 수 있다.

 

기능이 추가되는 경우 소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양이 최소화될 것이다.

(이상적인 변경량을 0이다.)

 

How?

SRP: 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고,

DIP: 요소 사이의 의존성을 체계화함으로써 변경량을 최소화할 수 있다.

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

 

Presenter 에서 발생한 변경으로부터 Controller 를 보호, View 변경으로부터 Presenter 보호

Interactor 는 다른 모든 것에서 발생한 변경으로부터 보호하고자 함

• Interactor 는 OCP를 가장 잘 준수할 수 있는 곳에 위치한다.
  다른 클래스의 어떤 변경도 영향을 주지 않음

Why?

Interactor 가 업무 규칙을 포함하기 때문에

• Interactor 는 가장 높은 수준의 정책을 포함한다.
• Interactor 이외의 컴포넌트는 모두 주변 문제를 처리하고, Interactor 는 가장 중요한 문제를 담당한다.
• 중심적인 문제 담당 Interactor > Controller > Presenter > View

→ 아키텍처 수준에서 OCP 가 동작하는 방식

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

→ 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있다.

 

방향성 제어

FinancialGateway 인터페이스는 FinancialReportGenerator 와 FinancialDataMapper 사이에 위치하는데, 의존성을 역전시키기 위해서이다.

인터페이스가 없었다면, Interactor 에서 DB 컴포넌트로 바로 향하게 된다.

정보 은닉

FinancialReportRequester 인터페이스는 컨트롤러가 Interactor 내부에 대해 너무 많이 알지 못하도록 막기 위해서 존재한다. 만약 이 인터페이스가 없었다면, 컨트롤러가 엔티티에 대해 추이 종속성을 가지게 된다.

추이 종속성을 가지게 되면, 소프트웨어 엔티티는 ‘자신이 직접 사용하지 않는 요소에는 절대로 의존해서는 안된다’는 원칙을 위반하게 된다.

Controller 에서 발생한 변경으로부터 Interactor 를 보호하는 일의 우선순위가 가장 높지만, Interactor 에서 발생한 변경으로부터 Controller 도 보호되기를 바란다. → 이를 위해 Interactor 내부를 은닉한다.

나는 정보 은닉이 class 의 멤버를 private 으로 하는것을 보고 정보 은닉이라고 하는거라고 알고 있었어서 그동안도 이게 그렇게 특징일 만큼 중요한 부분인가? 라고 생각했는데, interface 나 추상 클래스를 통해 실제 동작을 가리고 다른 곳에서 일어나는 변경으로부터 보호하기 위해 사용되는 것도 정보 은닉이라고 해서 신기했다.
내가 그동안 알던 것보다 훨씬 많은게 숨어있었던것 같다.

결론

OCP 의 목표

• 시스템을 확장하기 쉽게 & 변경으로 인해 시스템이 너무 많은 영향을 받지 않게 하는 것

1. 시스템을 컴포넌트 단위로 분리
2. 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어지도록 해야 함