13. 컴포넌트 응집도

REP: 재사용/릴리즈 등가 원칙(Reuse/Release Equivalence Principle)

재사용 단위는 릴리즈 단위와 같다.

 

새로운 버전이 언제 출시되고 무엇이 변했는지를 소프트웨어 개발자들이 알아야하기 때문에 소프트웨어 컴포넌트가 릴리즈 절차를 통해 추적, 릴리즈 번호가 부여해야한다.

또한, 적절한 릴리즈 공지와 릴리즈 문서작성도 포함되어야 개발자는 변경사항을 살펴보고 기존버전을 계속 쓸지를 결정한다.

 

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

이 원칙을 어기면 이치에 맞지 않게 된다. 

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

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

이 원칙은 단일 책임 원칙(SRP)을 컴포넌트 관점에서 다시 쓴 것.

SRP에서 단일 클래스는 변경의 이유가 여러 개 있어서는 안된다고 말하듯이 공통 폐쇄 원칙(CCP)에서도 마찬가지로 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안된다고 말한다.

 

대다수의 애플리케이션에서 유지보수성은 재사용성보다 훨씬 중요하다. 애플리케이션에서 코드가 반드시 변경되어야 한다면, 이러한 변경이 여러 컴포넌트 도처에 분산되어 발생하기보다는, 차라리 변경 모두가 단일 컴포넌트에서 발생하는 편이 낫다. 변경된 해당 컴포넌트만 재배포하면 된다.

SRP와의 유사성

ccp는 컴포넌트 수준의 SRP다.  두 원칙은 동일한 교훈을 가지고 있다. 

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

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

컴포넌트 사용잘들은 필요하지 않은 것에 의존하게 강요하지 말라.

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

컨테이너 클래스와 해당 클래스의 iterator 클래스, 이 들 클래스는 서로 강하게 결합되어 있기 때문에 함께 재사용횐다. 다라서 이들 클래스는 반드시 동일한 컴포넌트에 위치해야한다. 

의존하는 컴포넌트가 있다면 해당 컴포넌트의 모든 클래스에 대해 의존함을 확실히 인지해야한다.

일부 클래스에만 의존하고 다른 클래스와는 독립적일 수 없음을 확실히 인지해야한다. 그렇지 않다면 필요이상으로 많은 컴포넌트를 재배포하느라 노력을 허비하게 된다.

ISP와의 관계

CRP는 인터페이스 분리 원칙(ISP)의 포괄적인 버전이다.

두 원칙은 한문장으로 요약할 수 있다.

"필요하지 않은 것에 의존하지 말라."

컴포넌트 응집도에 대한 균형 다이어그램

응집도에 대한 세 원칙이 서로 상충된다.

REP와 CCP는 포함 원칙. 두 원칙은 컴포넌트를 더욱 크게 만든다.

CRP는 배제 원칙. 컴포넌트를 더욱 작게 만든다.

 

[REP: 재사용성을 위한 그룹] - <컴포넌트 변경이 너무 빈번함>- [CRP: 불필요한 릴리즈를 피하기 위해 분리하기]

[CCP: 유지보수성을 위한 그룹]- <재사용이 어려움>- [CRP: 불필요한 릴리즈를 피하기 위해 분리하기]

[CCP: 유지보수성을 위한 그룹] -<불필요한 릴리즈가 너무 빈번함>-[REP: 재사용성을 위한 그룹]

 

결론

컴포넌트 응집도에 관한 세가지 원칙은 응집도가 가질 수 있는 복잡한 다양성을 설명해 준다.

어느 클래스들을 묶어서 컴포넌트로 만들지 결정할 때, 재사용성과 개발가능성이라는 상충하는 힘을 반드시 고려해야한다. 이 사이에서 애플리케이션의 요구에 맞게 균형을 잡는 일이 중요하다. 

시간의 흐름에 따라 프로젝트의 초점이 개발가능성에서 재사용성으로 바뀌고 그에 따라 컴포넌트를 구성하는 방식도 조금씩 흐트러지고 또 진화한다.