: 어떤 클래스를 어느 컴포넌트에 포함시켜야 할까?
REP: 재사용/릴리스 등가 원칙
재사용 단위는 릴리스 단위와 같다.
: 메이븐, 그래들 같은 모듈 관리 도구가 우후죽순으로 등장, 이 같은 도구들은 점점 중요해져갔음
: 이는 재사용 가능한 컴포넌트나 컴포넌트 라이브러리가 엄청나게 많이 만들어졌기 때문, 즉 우리는 소프트웨어 재사용의 시대에 살고 있는 것임
: 어찌보면 REP은 매우 당연해보이는 원칙임, 소프트웨어 컴포넌트가 릴리즈 절차를 통해 추적 관리되지 않는다면 해당 컴포넌트를 재사용하고 싶어도 사용할 수가 없음.
: 또한 릴리즈 번호가 존재하지 않는다면 재사용 컴포넌트들이 서로 호환되는지 보증할 방법이 없다. 외에도 변경사항들을 파악하기가 어려움
: 릴리즈 절차에는 적절한 공지와 함께 문서 작성이 포함되어야 함
: 이 원칙은 소프트웨어 설계와 아키텍처 관점에서 단일 컴포넌트는 응집성 높은 클래스와 모듈로 구성되어야함을 뜻함
: 컴포넌트를 구성하는 모든 모듈은 서로 공유하는 관심사? 목적이 있어야함
CCP: 공통 폐쇄 원칙
동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라, 서로 다른 시점에 다른 이유로 변경되는 클래스는 분리하라
: 이 원칙은 단일 책임 원칙을 컴포넌트 관점에서 다시 쓴 것, SRP에서 단일 클래스는 변경의 이유가 여러 개 있어서는 안 된다고 설명하듯이 공통 폐쇄 원칙에서도 마찬가지로
: 단일 컴포넌트는 변경의 이유가 여러개 있어서는 안된다고 말함
: 대다수의 애플리케이션에서 유지보수성은 재사용성보다 훨씬 중요함. 애플리케이션의 코드가 반드시 변경되어야 한다면 이러한 변경이 분산되어 변경되기보다 단일 컴포넌트에서
발생하는 것이 낫다.
: CCP는 같은 이유로 변경될 소지가 있는 클래스들은 모두 한곳으로 묶을 것을 권한다. 물리적, 개념적으로 강하게 결합되어 항상 함께 변경되는 클래스는 하나의 컴포넌트에 속한다.
•
SRP와의 유사성
: CCP는 컴포넌트 수준의 SRP다. SRP에서는 서로 다른 이유로 변경되는 메서드를 서로 다른 클래스로 분리하라고 말한다.
: CCP에서는 서로 다른 이유로 변경되는 클래스를 서로 다른 컴포넌트로 분리하라고 말한다.
⇒ 동일한 시점에 동일한 이유로 변경되는 것들을 한데 묶어라. 서로 다른 시점에 다른 이유로 변경되는 것들은 서로 분리하라
CRP: 공통 재사용 원칙
컴포넌트 사용자들을 필요하지 않는 것에 의존하게 강요하지 말라
: 공통 재사용 원칙도 클래스와 모듈을 어느 컴포넌트에 위치시킬지 결정할 때 도움이되는 원칙, CRP에서는 같이 재사용되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함
: 컨테이너 클래스와 해당 클래스의 이터레이터 클래스는 강결합이므로 통일한 컴포넌트에 위치해야 한다.
: CRP는 동일한 컴포넌트로 묶어서는 안되는 클래스가 무엇인지도 얘기해준다.
: 변경되는 컴포넌트를 사용하는 클래스가 하나만 있는 컴포넌트에서도 컴포넌트간 의존성이 발생한다.
: 즉 강하게 결합되지 않는 클래스들을 동일한 컴포넌트에 위치시켜서는 안된다고 설명한다.
•
ISP와의 관계
: CRP는 인터페이스 분리원칙의 포괄적인 버전이다.
: ISP는 사용하지 않는 메서드가 있는 클래스에 의존하지 말라고 한다.
: CRP는 사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말라고 한다.
⇒ 필요하지 않는 것에 의존하지 말아라
컴포넌트 응집도에 대한 균형 다이어그램
: 응집도에 관련된 세가지 원칙은 서로 상충된다
결론
: 어느 클래스들을 묶어서 컴포넌트로 만들지 결정할때, 재사용성과 개발 가능성이라는 상충하는 힘을 반드시 고려해야 한다.
