SOLID 설계원칙 - 8장. OCP: 개방-폐쇄 원칙(Open-Closed Principle)

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

1980년대 버트란트 마이어에 의해 유명해진 원칙.

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

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

OCP는 클래스와 모듈을 설계할 때 도움 되는 원칙으로 알고 있지만 아키텍처 컴포넌트 수준에서 중요한 의미를 가진다.

사고 실험

제무제표를 웹페이지를 보여주는 시스템이 존재한다고 가정하자.

프린터로 출력하는 기능을 추가하도록 요청했다고 하자.

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

 

단일 책임 원칙을 적용하여 재무 데이터를 검사한 후 보고서용 데이터를 생성한 다음 필요에 따라 두 가지 보고서 생성 절차(PDF 보고서/WEB 보고서) 중 하나를 거쳐 적절히 포매팅한다.

 

여기서 중요한 포인트!

보고서 생성이 두개의 책임으로 분리됨 (보고서용 데이터를 계산, 프린트하는 형태에 따른 표현)

• 행위가 확장될 때 변경이 발생하지 않음을 보장하기 위해서는
  • 책임을 분리→ 소스코드 의존성도 확실히 조직화해야 한다.
  1. 처리 과정을 클래스 단위로 분할
  2. 컴포넌트 단위로 구분한다.

화살표는 Using(사용) 관계, implement(구현) 관계 또는 inheritance(상속) 관계이다.

화살표가 A클래스에서 B클래스로 향한다는 의미 : A클래스에서는 B클래스를 호출하지만 B클래스에서는 A클래스를 전혀 호출하지 않음을 뜻함.

 

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

화살표는 변경으로부터 보호하려는 컴포넌트를 향하도록 그려진다.

 

가장 중요한 문제를 다루는(업무규칙을 포함하는) Interactor는 다른 어떤 곳에서 발생한 변경도 Interactor에 영향을 주지 못한다.

보호의 계층구조가 수준(Level)이라는 개념을 바탕으로 존재한다.

가장 높은 수준의 개념은 최고의 보호를 받으며, 가장 낮은 수준의 개념(View)은 거의 보호를 받지 못한다.

 

아키텍트는 기능이 어떻게, 왜, 언제 발생하는지에 따라서 기능을 분리하고 분리한 기능을 컴포넌트의 계층구조로 조직화한다. 이와 같이 조직화하면 저 수준 컴포 먼트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있다.

방향성 제어

컴포넌트 간 의존성을 역전시키기 위해 FinancialDataGateway와 FinancialDataMapper사이에 FinancialReportGenerator 인터페이스를 위치시켰다. 이 인터페이스가 없었다면 의존성이 Interactor 컴포넌트에서 Database 컴포넌트로 바로 향하게 된다.

정보 은닉

FinancialReportRequester 인터페이스는 방향성 제어가 아닌 내부를 감추기 위한 목적으로 존재한다.

이 인터페이스가 없었다면 Controller는 FinancialEntities에 대해 추이 종속성을 가지게 된다.

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

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

결론

OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 데 있다. 이를 달성하려면 컴포넌트 단위로 분리하고 저수준에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조를 만들어야 한다.