[Clean Architecture] 9. SOLID 원칙 - OCP (Open Closed Principle)

OCP

• 개념: 기능이 추가될때 소프트웨어 개체는 확장을 하는 방향이며, 변경은 최소화
  
  • 더욱 정확한 개념: 의존관계를 잘 설정하여 특정 항목이 변경되어도 중요한 interactor같은 컴포넌트는 변경하지 않아도 되는 형태
• 목적: 시스템을 확장하기 쉬운 동시에 변경으로 인해 시스템이 너무 많은 영향을 받지 않도록 하는 것

OCP 아이디어

• 아이디어: A, B 관계에서 A컴포넌트에서 변경 발생 -> B컴포넌트는 수정하지 않는 방법?
  • B컴포넌트가 A컴포넌트에 의존하고 있지 않으면 해결
  • 의존성을 관리하려면 Interface를 통해 의존 관계를 변경

예시

• View에서 변경 -> Presenter 보호
• Presenter에서 변경이 발생 -> Controller 보호
• View, Presenter, Controller, Database에서 변경 발생 -> Interactor 보호
  • Interactor가 가장 보호받는 이유: 가장 높은 수준의 정책을 포함하고 나머지들은 주변 문제들을 처리하기 때문
  • 수준(level)을 나누어서 가장 보호받아야 하는 것 위주로 설계: View < Presenter < Controller, Database < Interactor

OCP를 준수한 구조

• 방향성 제어
  • Database로부터 Interactor보호하기 위해서 Financial Report Generator에서 Financial Data mapper로 참조하고 있지 않은 형태
  • Interface를 통해 의존이 Interactor에서 Database로 가지 않고 '의존 방향이 역전'

• 정보 은닉, 응집성(cohesion)
  • Financial Report Requester는 방향성 제어의 의미도 있지만, 진정한 목적은 Controller가 Interactor 내부에 대해 많이 알지 못하도록 하는 목적
  • 만약 이 interface가 없다면 Controller는 Interactor에 대해서 추이 종속성(transitive dependency) 소유
    * 추이 종속성: A가 B에 의존, B가 c에 의존하면 곧 A가 C에 의존하는 형태
  • 추이 종속성을 갖으면 '자신이 직접 사용하지 않는 요소에는 절대로 의존하면 안된다는 클린 소프트웨어 원칙 어긋나는 형태'

OCP를 준수한 경우 얻을 수 있는 이점

• 정보 은닉(Cohesion): 
• 방향성 제어 DIP(Dependency Inversion): 

* 참고

Clean Architecture