# OCP란?
확장에는 열려 있어야 하고, 변경에는 닫혀 있어야 한다.
즉, 책임을 확실히 분리하도록 소스 코드 의존성을 확실히 조직화해야 한다.
# 예시
## 컴포넌트 관계는 단방향
A 클래스 -> B 클래스라면, A 클래스는 B 클래스에 대한 의존성을 가지고 있지만 B 클래스는 A 클래스에 대해 전혀 모르는 상태.
(A 클래스가 수정되더라고 B 클래스는 수정되지 않음.)
나아가서 A 컴포넌트 -> B 컴포넌트라면, A 컴포넌트는 B 컴포넌트에 대해 의존하고 있음. 즉, A 컴포넌트에서 발생한 변경으로부터 B 컴포넌트가 보호됨.
위 그림을 예를 들면, Presenter에서 발생한 변경으로부터 Controller는 보호되고, Controller에서 발생한 변경으로부터 Interactor가 보호됨.
## 방향성 제어
FinancialDataGateway 인터페이스는 의존성을 역전시키기 위해 존재함.
만약 FinancialDataGateway 인터페이스가 없었다면 의존성이 Interactor -> Database (FinancialReportGenerator -> FinancialDataMapper)가 되기 때문에 컴포넌트 간 단방향성 규칙이 깨지게 됨.
## 정보 은닉
FinancialReportRequester 인터페이스는 Interactor 내부를 추상화하기 위해 만들어짐.
만약 FinancialReportRequester 인터페이스가 없다면 Controller는 FinancialEntities에 대해 추이 종속성(transitive dependency)을 가지게 됨.
[참고] 추이 종속성(transitive dependency)란?
A -> B 그리고 B -> C 일 때, A가 C에 의존하게 되는 경우를 추이 종속성이라고 부른다.
# 결론
- 컴포넌트 단위로 잘 분리
- 저수준 컴포넌트에서 발생한 변경으로부터 고수준 컴포넌트를 보호할 수 있는 형태의 의존성 계층구조 만들기
# 참고
Robert C. Martin. 『클린 아키텍처』. 인사이트, 2019.
이번 글은 여기서 마무리.
'Clean Architecture' 카테고리의 다른 글
[SOLID] SRP (Single Responsibiliy Principle) (0) | 2024.06.17 |
---|