-
Notifications
You must be signed in to change notification settings - Fork 0
14장 컴포넌트 결합
컴포넌트 의존성 그래프에 순환(cycle)이 있어서는 안된다.
동일한 소스파일을 수정하는 환경에서 동작되던 기능이 다른 사람으로 인해 동작하지 않을 때는 숙취 증후군이라고 부른다. 숙취 증후군을 해결하기 위해서 ADP 원칙을 사용한다.
이상적인 구조는 비순환 방향 그래프(Directed Acyclic Graph, DAG) 형태로 컴포넌트가 조립된 것이다. 순환 의존성(Dependency Cycle)이 발생하면 컴포넌트를 어떤 순서로 빌드해야 하는 지 알 수 없다.
순환 의존성에서 DAG로 복구하기 위해서는 DIP를 적용한다. DAG에서 순환 의존성이 발생하지 않도록 SRP와 CCP에 관심을 가져야 한다.
안정성의 방향으로(더 안정된 쪽에) 의존하라.
안정성은 변경을 만들기 위해 필요한 작업량과 관련된다. 소프트웨어 컴포넌트를 변경하기 어렵게 만드는 데는 많은 요인이 존재하며, 그 예로는 컴포넌트의 크기, 복잡도, 간결함 등을 들 수 있다.
DIP를 통해 I를 낮출 수 있다.
어떻게 하면 컴포넌트 안정성을 측정할 수 있을까? 컴포넌트로 들어오고 나가는 의존성의 개수를 세어보는 방법이 있을 수 있다. 이 숫자를 통해 컴포넌트가 위치상(Positional) 어느 정도의 안정성을 가지는 지 계산할 수 있다.
- Fan-in: 안으로 들어오는 의존성.
- Fan-out: 바깥으로 나가는 의존성.
- I(불안정성): I=Fan-out / (Fan-in + Fan-out). [0, 1] 범위값을 같는다. I=0이면 최고로 안정된 컴포넌트라는 뜻이다. I=1이면 최고로 불안정한 컴포넌트라는 뜻이다.
컴포넌트는 안정된 정도 만큼만 추상화되어야 한다.
안정된 추상화 원칙은 안정성과 추상화 정도 사이의 관계를 정의한다. 이 원칙은 한편으로는 안정된 컴포넌트는 추상 컴포넌트여야 하며, 이를 통해 안정성이 컴포넌트를 확장하는 일을 방해해서는 안된다고 말한다.
따라서 안정적인 컴포넌트라면 반드시 인터페이스와 추상 클래스로 구성되어 쉽게 확장할 수 있어야 한다. 안정된 컴포넌트가 확장이 가능해지면 유연성을 얻게 되고 아키텍처를 과도하게 제약하지 않게 된다.
SAP와 SDP를 결합하면 컴포넌트에 대한 DIP나 마찬가지가 된다. 실제로 SDP에서는 의존성이 반드시 안정성의 방향으로 향해야 한다고 말하며, SAP에서는 안정성이 결국 추상화를 의미한다고 말하기 때문이다. 따라서 의존성은 추상화의 방향으로 향하게 된다.
- Nc: 컴포넌트의 클래스 개수
- Na: 컴포넌트의 추상 클래스와 인터페이스 개수
- A: 추상화 정도. A=Na / Nc
A 지표는 0과 1사이의 값을 갖는다. A가 0이면 컴포넌트에는 추상 클래스가 하나도 없다는 뜻이다. A가 1이면 컴포넌트는 오로지 추상 클래스만을 포함한다는 뜻이다.