Clean Architecture

[SOLID] OCP (Open-Closed Principle)

Phililip
728x90

# 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