컴포넌트 응집도

• 컴포넌트 응집도에서 클래스와 모듈을 어느 컴포넌트에 위치시킬지 결정할 때 도움되는 원칙들을 살펴본다.

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

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

• 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적을 기준으로 구성되어야 한다.
• 하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 하며, 동일한 릴리스로 추적 관리되고, 동일한 릴리스 문서에 포함되어야 한다.
  • 릴리즈 버전이 1.0이라면 컴포넌트와 컴포넌트를 구성하는 클래스 버전도 1.0이어야 한다.
    • 쿠팡, 넷플릭스는 최신 버전으로 업데이트 하지 않아도 기존 버전을 계속 사용할 수 있다. 사용자 입장에선 항상 업데이트할 귀찮음에서 벗어날 수 있고, 개발자 입장에선 릴리즈 버전 별로 오류나 변경요구사항을 처리할 수 있게 되는 것임.
    • Git 소스코드 버전 관리도 예시가 될수 있겠음.
• 굳이 왜 버전 버전과 컴포넌트 버전을 붙여야 하는가?
  • 예를 들어 레트로핏 3.0이 배포 되었지만, 레트로핏 2.0 버전도 사용할 수 있어야 한다.
  • 레트로핏 공식문서 보면 버전별 문서화가 되어 있고, 해당 문서를 보면서 사용여부를 결정할 수도 있다.

CCP: 공통 폐쇄 원칙

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

• 단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안 된다.
  • CCP는 SRP의 단일 클래스는 변경의 이유가 여러 개 있어서는 안 된다고 한 것을 컴포넌트 수준에서 바라보는 관점이다.
    • SRP장에서 Employee 클래스에 CTO, CFO, COO가 필요한 메서드를 한 곳에 모았다가 CTO,CFO,COO 각 클래스로 분리시켜, 서로 영향을 받지 않도록 분리 한 경우를 생각.
  • 애플리케이션의 유지보수성을 강조하는 원칙이다.
• CCP는 같은 이유로 변경될 가능성이 있는 클래스는 모두 한곳으로 묶을 것을 권한다.

CRP: 공통 재사용 원칙

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

묶어야 할 클래스 설명

• 개별 클래스가 단독으로 재사용되는 경우는 거의 없음.
• 대체로 재사용 가능한 클래스는 재사용 모듈의 일부로써 해당 모듈의 다른 클래스와 상호작용하는 경우가 많기 때문에 서로간의 의존성도 있을 가능성이 크다. CRP에서는 이런 클래스들이 동일한 컴포넌트에 포함되어야 한다고 말한다.
  • container 클래스와 iterator 클래스

묶지 말아야 할 클래스 설명

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

ISP와의 관계

• ISP는 사용하지 않은 메서드가 있는 클래스에 의존하지 말라고 조언.
• CRP는 사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말라고 조언.

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

• REP와 CCP는 포함원칙이라 컴포넌트를 크게 만들고, CRP는 배제원칙이라 컴포넌트를 작게 만든다.
• 어떻게 균형을 이룰 것인가?

이미지 출처 : https://icarus8050.tistory.com/46

REP와 CRP 집중할 경우

• 사소한 변경이 생겼을 때 너무 많은 컴포넌트에 영향을 미침.

CCP와 REP 집중할 경우

• 불필요한 릴리스가 너무 빈번해짐.

• 결국 프로젝트의 컴포넌트 구조는 시간과 성숙도에 따라 변화한다.

  • 프로젝트 초기에는 CCP가 REP보다 훨씬 중요한데, 개발 가능성이 재사용성보다 중요하기 때문.
  • 일반적으로 프로젝트는 삼각형의 오른쪽에서 시작하는 편이며, 이때는 오직 재사용성만 희생하면 됨.
  • 프로젝트가 성숙하고, 파생된 또 다른 프로젝트가 시작되면 프로젝트는 삼각형에서 점차 왼쪽으로 이동한다.