Principles of Component Cohesion (REP, CCP, CRP)

* REP (Reuse/Release Equivalence Principle; 재사용/릴리스 등가 원칙)

> 재사용 단위는 릴리스 단위와 같다

: 릴리스 번호가 없다면 재사용 컴포넌트들이 서로 호환되는지 보증할 방법이 전혀 없다

: 새로운 버전이 언제 출시되고 무엇이 변했는지를 소프트웨어 개발자들이 알아야 하기 때문이다

: 아키텍트 관점에서 보면 단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다
    (컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다)

* CCP (Common Closure Principle; 공통 폐쇄 원칙)

> 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라. 서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라

: SRP 원칙을 컴포넌트 관점에서 다시 쓴 것이다
: 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안 된다

: 변경을 단일 컴포넌트로 제한할 수 있다면, 해당 컴포넌트만 재배포하면 된다

: 이를 통해 소프트웨어 릴리스, 재검증, 배포하는 일과 관련된 작업량을 최소화할 수 있다

: OCP 에서 얻은 교훈을 확대 적용한다

* CRP (Common Reuse Principle; 공통 재사용 원칙)

> 컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라

: 클래스와 모듈을 어느 컴포넌트에 위치시킬지 결정할 때 도움되는 원칙이다

: 같이 재사용되는 경향이 있는클래스와 모듈들은 같은 컴포넌트에 포함해야 한다

: 강하게 결합되지 않은 클래스들을 동일한 컴포넌트에 위치시켜서는 안된다

  (어떤 컴포넌트가 다른 컴포넌트의 단 하나의 클래스만을 사용하더라도 의존성은 약해지지 않으며 해당 컴포넌트 전체에 대해 의존성을 가진다)

: ISP 원칙의 포괄적인 버전이다

* The Tension Diagram For Component Cohesion (컴포넌트 응집도에 대한 균형 다이어그램)

> 각 변은 반대쪽 꼭지점에 있는 원칙을 포기했을 때 감수해야 할 비용을 나타낸다

> 3가지 원칙이 서로 상충된다

: REP, CCP 는 포함 원칙으로 컴포넌트를 더욱 크게 만든다. CRP 는 배제 원칙이며 컴포넌트를 더욱 작게 만든다