4부 컴포넌트 원칙

12장 컴포넌트

컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위다.

 

13장 컴포넌트 응집도

이 장에서는 컴포넌트 응집도와 관련된 세 가지 원칙을 논의한다.

• REP: 재사용/릴리스 등가 원칙
• CCP: 공통 폐쇄 원칙
• CRP: 공통 재사용 원칙

REP: 재사용/릴리스 등가 원칙

이 원칙을 소프트웨어 설꼐와 아키텍처 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻하다.

 

CCP: 공통 폐쇄 원칙

• 동일한 이유로 동일한 시점에 변경되는 클래스르 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라.
• 이 원칙은 단일 책임 원칙을 컴포넌트 관점에서 다시 쓴 것이다.
• 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안 된다고 말한다.

SRP와의 유사성

동일한 시점에 동일한 이유로 변경되는 것들을 한데 묶어라. 서로 다른 시점에 다른 이유로 변경되는 것들을 서로 분리하라.

 

CRP: 공통 재사용 원칙

• 컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라.
• CRP에서는 같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함해야 한다고 말한다.
• CRP는 강하게 결합되지 않은 클래스들을 동일한 컴포넌트에 위치시켜서는 안된다고 말한다.

ISP와의 관계

• CRP는 인터페이스 분리 원칙의 포괄적인 버전이다. ISP는 사용하지 않은 메서드가 있는 클래스에 의존하지 말라고 조언한다. CRP는 사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말라고 조언한다.
• 필요하지 않은 것에 의존하지 말라.

14장 컴포넌트 결합

ADP: 의존성 비순환 원칙

• 컴포넌트 의존성 그래프에 순환이 있어서는 안된다.

주 단위 빌드

개발보다 통합에 드는 시간이 늘어나면서 팀의 효율성도 서서히 나빠진다.

 

순환 의존성 제거하기

• 이 문제의 해결책은 개발 환경을 릴리스 가능한 컴포넌트 단위로 분리하는 것이다. 이를 통해 컴포넌트는 개별 개발자 또는 단일 개발팀이 책임질 수 있는 작업 단위가 된다.
• 각 팀은 특정 컴포넌트가 새롭게 릴리스되면 자신의 컴포넌트를 해당 컴포넌트에 맞게 수정할 시기를 스스로 결정할 수 있다. 뿐만 아니라 통합은 작고 점진적으로 이뤄진다.
• 의존성 구조에 순환이 있어서는 안 된다. 의존성 구조에 순환이 생기면 '숙취 증후군'을 피해 갈 수 없다.
• 이 구조는 비순환 방향 그래프다.
• 시스템 전체를 릴리스해야 할 때가 오면 릴리스 절차는 상향식으로 진행된다.
• 구성요소 간 의존성을 파악하고 있으면 시스템을 빌드하는 방법을 알 수 있다.

 

순환이 컴포넌트 의존성 그래프에 미치는 영향

• 순환이 생기면 컴포넌트를 분리하기가 상당히 어려워진다. 단위 테스트를 하고 릴리스를 하는 일도 괭장히 어려워지며 에러도 쉽게 발생한다. 게다가 모듈의 개수가 많아짐에 따라 빌드 관련 이슈는 기하급수적으로 증가한다.

순환 끊기

의존성 역전 원칙을 적용한다.

 

흐트러짐

요구사항이 변경되면 컴포넌트 구조도 변경될 수 있다는 사실이다.

 

하향식 설계

• 컴포넌트는 시스템에서 가장 먼저 설계할 수 있는 대상이 아니며, 오히려 시스템이 성장하고 변경될 때 함계 진화한다.
• 컴포넌트 의존성 다이어그램은 애플리케이션의 빌드 가능성과 유지보수성을 보여주는 지도와 같다.
• 결국 컴포넌트 의존성 그래프는 자주 변경되는 컴포넌트로부터 안정적이며 가치가 높은 컴포넌트를 보호하려는 아키텍트가 만들고 가다듬게 된다.

SDP: 안정된 의존성 원칙

• 안정성의 방향으로 (더 안정된 쪽에) 의존하라.
• 변경이 쉽지 않은 컴포넌트가 변동이 예상되는 컴포넌트에 의존하게 만들어서는 절대로 안 된다.

안정성

소프트웨어 컴포넌트를 변경하기 어렵게 만드는 확실한 방법 하나는 수많은 다른 컴포넌트가 해당 컴포넌트에 의존하게 만드는 것이다.

 

모든 컴포넌트가 안정적이어야 하는 것은 아니다.

사실 우리가 컴포넌트 구조를 설계할 때 기대하는 것은 불안정한 컴포넌트도 있고 안정된 컴포넌트도 존재하는 상태다

 

SAP: 안정된 추상화 원칙

고수준 정책을어디에 위치시켜야 하는가?

컴포넌트가 최고로 안정된 상태이면서도 동시에 변경에 충분히 대응할 수 있을 정도로 유연하게 만들 수 있을까? 해답은 개방 폐쇄 원칙에서 찾을 수 있다.

 

안정된 추상화 원칙

안정적인 컴포넌트라면 반드시 인터페이스와 추상 클래스로 구성되어 쉽게 확장할 수 있어야 한다. 안정된 컴포넌트가 확장이 가능해지면 유연성을 얻게 되고 아키텍처를 과도하게 제약하지 않게 된다.