intro
컴포넌트는 시스템에서 먼저 설계할 수 있는 대상이 아니며, 시스템이 성장하고 변경될 때, 진화하는 대상이다.
따라서, software가 계속 성장함에 따라, 재사용성을 위해 컴포넌트 의존 관계를 수정해야 한다.
이와 관련해서 컴포넌트 관계 3가지 원칙이 있고, 이를 알아보고자 한다.
ADP(Acyclic Dependencies Principle): 의존성 비순환 원칙
컴포넌트 간의 의존성 그래프는 단방향이어야 한다.
왜? 서로 의존하는 컴포넌트 관계이면, 개별로 릴리즈 할 수 없기 때문이다.
즉, 순환 의존성 관계의 컴포넌트들이 하나의 컴포넌트처럼 서로 얽매이게 된다.
예를 들어, 아래 그림을 보자.
Entities → Authorizer → Interactors → Entites 가 순환 의존성을 가져, 3개가 하나의 거대한 컴포넌트가 된다. 이는 Database를 릴리즈 하는 개발자가, Entities 뿐만 아니라, Authorizer, Interactors 모두 고려하도록 만든다.
그렇다면, 우리는 순환 의존성을 어떻게 제거할 수 있을까?
1. DIP(의존성 역전 원칙)을 적용한다.
2. 새로운 컴포넌트를 추가한다.
예를 들어, Entities와 Authorizer 가 모두 의존하는 새로운 컴포넌트를 추가한다.
SDP(Stable Dependencies Principle): 안정된 의존성 원칙
더 안정된 쪽(더 바뀌지 않는 쪽)에 의존하라.
의존하는 대상이 바뀌면 그 영향을 받기 때문이다.
안정성 지표
컴포넌트 안정성을 어떻게 측정할 수 있을까? 우리는 컴포넌트로 들어오고(Fan-in) 나가는(Fan-out) 의존성 개수를 통해 안정성 지표를 계산할 수 있다.
cf. Fan-in은 나를 의존하는 컴포넌트가 많다. 이는 나를 바꾸기 어렵게 만든다. stable 하다.
cf. Fan-out은 내가 의존하는 컴포넌트가 많다. 이는 나를 바꾸기 쉽게 만든다. unstable 하다.
I (불안정성) = Fan-out / (Fan-in + Fan-out)
즉, 나보다 I가 낮은(더 안정적인) 컴포넌트를 의존해야 한다.
그렇다면, 우리는 안정된 의존성을 어떻게 지킬 수 있을까?
1. DIP(의존성 역전 원칙)을 적용한다.
2. 추상 컴포넌트; 인터페이스만을 포함하는 컴포넌트
SAP(Stable Abstractions Principle): 안정된 추상화 원칙
컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
즉, 안정성이 추상화를 의미한다.
컴포넌트가 안정된 상태이면서, 동시에 변경에 충분히 대응할 수 있도록 할 수 없을까?
이를 만족할 수 있는 것은 추상 클래스이다. 왜냐하면, 추상 클래스는 확장에는 열려있고, 변경에는 닫혀있기 때문이다.
추상화 지표
A (추상화 정도) = 추상화 클래스와 인터페이스 수 / 클래스 개수
불안정성(I)과 추상화(A) 사이의 관계 그래프를 보자.
고통의 구역
구체적이고, 안정성이 높다.
구체 클래스가 많은 컴포넌트이고, 이를 의존하는 다른 컴포넌트들이 많다.
그러므로, 해당 컴포넌트에 변경이 발생하는 경우, 변경이 쉽지 않다.
쓸모없는 구역
추상적이고, 불안정성이 높다.
추상 클래스가 많은 컴포넌트이고, 이를 의존하는 다른 컴포넌트들이 적다.
변경하기 쉬운 컴포넌트라, 추상 클래스가 굳이 많을 필요가 없다. 쓸모없어!
주계열
우리는 추상적이고 안정성이 높은 컴포넌트, 또는 구체적이고 안정성이 낮은 컴포넌트를 원한다.
이는 주계열의 두 종점(0, 1), (1,0)이다. 그러나, 이는 이상적이다.
그래서, 우리는 주계열 바로 위에 또는 가깝게 있는 컴포넌트를 지향한다.
referennce
- Clean Architecture
- [Clean Architecture] 컴포넌트 사이의 관계와 원칙(3) : SAP (tistory.com)