동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어라

서로 다른 시점에 다른 이유로 변경되는 클래스는 다른 컴포넌트로 분리하라


...


대다수의 애플리케이션에서 유지보수성은 재사용성보다 훨씬 중요하다

애플리케이션에서 코드가 반드시 변경되어야 한다면, 이러한 변경이 여러 컴포넌트 도처에 분산되어 발생하기보다는,

차라리 변경 모두가 단일 컴포넌트에서 발생하는 편이 낫다


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

변경된 컴포넌트에 의존하지 않는 다른 컴포넌트는 다시 검증하거나 배포할 필요가 없다


CCP(공통 폐쇄 원칙)는 같은 이유로 변경될 가능성이 있는 클래스는 모두 한 곳으로 묶을 것을 권한다

물리적 또는 개념적으로 결합되어 항상 함께 변경되는 클래스들은 하나의 컴포넌트에 속해야 한다

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


이 원칙은 OCP와도 밀접하게 관련되어 있다 실제로 CCP에서 말하는 폐쇄는 OCP에서 말하는 폐쇄와 그 뜻이 같다

OCP에서는 클래스가 변경에는 닫혀 있고 확장에는 열려 있어야 한다고 말한다

100% 완전한 폐쇄란 불가능하므로 전략적으로 폐쇄해야 한다


우리는 발생할 가능성이 있거나 과거에 발생했던 대다수의 공통적인 변경에 대해서 클래스가 닫혀 있도록 설계한다


앞서 언급했듯이, CCP는 컴포넌트 수준의 SRP다

SRP에서는 서로 다른 이유로 변경되는 메서드를 서로 다른 클래스로 분리하라고 말한다

CCP에서는 서로 다른 이유로 변경되는 클래스를 서로 다른 컴포넌트로 분리하라고 말한다

두 원칙은 모두 다음과 같은 교훈으로 요약할 수 있다


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