: 소프트웨어 개체는 확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
⇒ 소프트웨어 개체의 행위는 확장할 수 있어야 하지만 이때 산출물을 변경해서는 안 된다.
: 만약 요구사항을 살짝 확장하는 데 소프트웨어를 엄청나게 수정해야 한다면 그 소프트웨어 시스템을 설계한 아키텍트는 엄청난 실패작인 것
: OCP는 클래스와 모듈을 설계할 때, 도움되는 원칙이라고 알려져 있으나 아키텍처 컴포넌트 수준에서 OCP를 고려하면 훨씬 중요한 의미를 가진다.
사고 실험
재무제표를 웹 페이지로 보여주는 시스템이 있다고 생각, 웹 페이지에 표시되는 데이터는 스크롤할 수 있으며 음수는 빨간색으로 출력됨
1.
해당 응용 프로그램의 이해관계자가 이 컬러 페이지를 보고서 형태로 변환해서 흑백 프린터로 출력해달라고 요청했다고 하자
2.
이 보고서에는 페이지 번호가 제대로 매겨져 있어야 하고 페이지마다 적절한 머리글과 바닥글이 있어야 하며 표의 각 열에는 레이블이 있어야할 때
3.
당연히 새로운 코드를 작성해야 하는데, 원래 코드는 얼마나 수정해야할까?
4.
소프트웨어 아키텍처가 훌륭하다면 변경되는 코드의 양은 이상적으론 0이다.
⇒ 어떻게 하면 될까? 서로 다른 목적으로 변경되는 요소를 적절하게 분리하고 이들 요소 사이의 의존성을 체계화하여 변경량을 최소화할 수 있다.
⇒ 여기서 얻을 수 있는 가장 중요한 영감은 보고서 생성이 두 개의 책임으로 분리된다는 사실, 하나는 보고서용 데이터를 계산하는 책임, 하나는 이 데이터를 웹, 출력해주는 것
: 이처럼 책임을 분리했다면 두 책임 중 하나에서 변경이 발생하더라도 다른 하나는 변경되지 않도록 소스 코드 의존성도 확실히 조직화해야 한다.
: 이러한 목적을 달성하려면 처리 과정을 클래스 단위로 분할하고 이들 클래스를 컴포넌트 단위로 구분해야 한다.
: 이 예제의 경우 Presenter에서 발생한 변경으로부터 Controller를 보호하고자 한다. 그리고 View에서 발생한 변경으로부터 Presenter를 보호하고자 한다.
: Interactor는 다른 모든 것에서 발생한 변경으로부터 보호하고자 한다.
: Interactor는 OCP를 가장 잘 준수할 수 있는 곳에 위치한다. DB, Cont, Presenter, View에서 발생한 어떠한 변경사항도 영향을 주지 않는다.
: 보호의 계층 구조가 어떻게 형성되는지 주목하자, Interactor → Controller → Presenter → View 순으로 보호되며 이는 아키텍처 수준에서 OCP가 동작하는 방식이다.
: 아키텍트는 기능이 어떻게, 왜, 언제 발생하는지에 따라서 기능을 분리하고 분리한 기능을 컴포넌트의 계층구조로 조직화한다.
결론
: OCP는 시스템의 아키텍처를 떠받치는 원동력 중 하나다. OCP의 목표는 시스템을 확장하기 쉬운 동시에 변경으로 인해 발생하는 영향을 최소화하는 데 있다.
: 이러한 목표를 달성하려면 컴포넌트 단위로 분리하고, 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조가 만들어지도록 해야한다.
