SOLID 원칙이 벽과 방에 벽돌을 배치하는 방법을 알려준다면,
컴포넌트 원칙은 빌딩에 방을 배치하는 방법을 설명해준다.큰 빌딩과 마찬가지로 대규모 소프틑웨어 시스템은 작은 컴포넌트들로 만들어진다.
컴포넌트는 시스템의 구성 요소로 배포할수 있는 가장 작은 단위다.
- Java의 경우, jar
- 루비의 경우, gem
- .NET의 경우, dll
- 컴파일형 언어의 경우, 바이너리 파일의 결합체
- 인터프리터형 언어의 경우, 소스 파일의 결합체
재사용 단위는 릴리스 단위와 같다.
- Reuse / Release Equivalence Principle
- 재사용 / 릴리스 등가 원칙
- 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 한다.
동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라.
서로 다른 시점에서 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.
- Common Closure Principle
- 공통 폐쇄 원칙
- 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안된다.
- SRP
- OCP
컴포넌트 사용자들은 필요하지 않는 것에 의존하게 강요하지 말라.
필요하지 않은 것에 의존하지 말라.
- Common Reuse Principle
- 공통 재사용 원칙
- 같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함해야 한다.
- ISP
컴포넌트 의존성 그래프에 순환(Cycle)이 있어서는 안된다.
- 의존성 비순환 원칙
- DIP를 통해 Cycle을 끊고, DAG(Directed Acyclic Graph)로 복구한다.
안정성의 방향으로 (더 안정된 쪽에) 의존하라.
- 안정된 의존성 원칙
Fan-in
: 안으로 들어오는 의존성Fan-out
: 바깥으로 나가는 의존성I = Fan-out / (Fan-in + Fan-out)
I = 0
: 안정된 컴포넌트I = 1
: 불안정한 컴포넌트컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
- 안정된 추상화 원칙
- 고수준 정책을 캡슐화하는 소프트웨어는 반드시 안정된 컴포넌트(I=0)에 위치해야 한다.
- 안정된 상태이면서도, 동시에 변경에 충분히 대응할 수 있을 정도로 유연하게 만들 수 있을까?
- OCP
- 추상화
Nc
: 컴포넌트 클래스 개수Na
: 컴포넌트의 추상 클래스와 인터페이스 개수A = Na / Nc
: 추상화 정도D = math.abs(A + I - 1)
: 이상적인 컴포넌트 상태로 얼마나 떨어져 있는지 측정하는 지표