[책 정리] 13장. 컴포넌트 응집도 - Clean Architecture

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

 

-

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

단일 컴포넌트는 응집성 높은 클래스와 모듈들로 구성되어야 함을 뜻한다.

컴포넌트를 구성하는 모든 모듈은 서로 공유하는 중요한 테마나 목적이 있어야 한다.

 

 

-

하나의 컴포넌트로 묶인 클래스와 모듈은 반드시 함께 릴리스할 수 있어야 한다.

하나의 컴포넌트로 묶인 클래스와 모듈은 버전 번호가 같아야 하며, 동일한 릴리스로 추적 관리되고, 동일한 릴리스 문서에 포함되어야 한다.

 

 

 

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

 

-

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

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

 

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

단일 컴포넌트는 변경의 이유가 여러 개 있어서는 안 된다.

 

 

-

대다수의 앱에서 유지보수성은 재사용성보다 훨씬 중요하다.

앱에서 코드가 반드시 변경되어야 한다면, 이러한 변경이 여러 컴포넌트 도처에 분산되어 발생하기보다는, 차라리 변경 모두가 단일 컴포넌트에서 발생하는 편이 낫다.

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

 

 

-

이 원칙은 개방 폐쇄 원칙(OCP)과도 밀접하게 관련되어 있다.

실제로 CCP 에서 말하는 폐쇄(closure)는 OCP 에서 말하는 폐쇄와 그 뜻이 같다.

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

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

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

 

 

* SRP(Single Responsibility Principle) 와의 유사성

 

-

CCP 는 컴포넌트 수준의 SRP 다.

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

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

 

 

 

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

 

-

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

 

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

개별 클래스가 단독으로 재사용되는 경우는 거의 없다.

대체로 재사용 가능한 클래스는 재사용 모듈의 일부로써 해당 모듈의 다른 클래스와 상호작용하는 경우가 많다.

CRP 에서는 이런 클래스들이 동일한 컴포넌트에 포함되어야 한다고 말한다.

 

 

-

CRP 는 동일한 컴포넌트로 묶어서는 안 되는 클래스가 무엇인지도 말해준다.

어떤 컴포넌트가 다른 컴포넌트를 사용하면, 두 컴포넌트 사이에는 의존성이 생겨난다.

어쩌면 사용하는 컴포넌트가 사용되는 컴포넌트에서 단 하나의 클래스만 사용할 수도 있다.

그렇다고 해서 의존성은 조금도 약해지지 않는다.

이 같은 의존성으로 인해 사용되는 컴포넌트가 변경될 때마다 사용하는 컴포넌트도 변경해야 할 가능성이 높다.

또는 사용하는 컴포넌트를 변경하지 않더라도, 재컴파일, 재검증, 재배포를 해야 하는 가능성은 여전히 남아 있다. 심지어 사용되는 컴포넌트에서 발생한 변경이 사용하는 컴포넌트와는 전혀 관련 없는 경우라도 말이다.

 

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

일부 클래스에만 의존하고 다른 클래스와는 독립적일 수 없음을 확실히 인지해야 한다.

 

 

-

CRP 는 어떤 클래스를 한 데 묶어도 되는지보다는, 어떤 클래스를 묶어서는 안 되는지에 대해서 훨씬 더 많은 것을 이야기한다.

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

 

 

* ISP(Interface Segregation Principle) 와의 관계

 

-

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

ISP 는 사용하지 않은 메서드가 있는 클래스에 의존하지 말라고 조언한다.

CRP 는 사용하지 않는 클래스를 가진 컴포넌트에 의존하지 말라고 조언한다.

 

 

 

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

 

-

REP 와 CCP 는 포함(inclusive) 원칙이다.

즉 두원칙은 컴포넌트를 더욱 크게 만든다.

 

CRP 는 배제(exclusive) 원칙이며, 컴포넌트를 더욱 작게 만든다.

 

뛰어난 아키텍트라면 이 원칙들이 균형을 이루는 방법을 찾아야 한다.

 

 

-

REP 와 CRP 에만 집중하면, 사소한 변경이 생겼을 때 너무 많은 컴포넌트에 영향을 미친다.

CCP 와 REP 만 과도하게 집중하면 불필요한 릴리스가 빈번해진다.

CCP 와 CRP 만 과도하게 집중하면 재사용이 어려워진다.

 

아키텍트는 적절한 위치를 찾아야 하며, 시간이 흐르면서 개발팀이 주의를 기울이는 부분이 변한다는 사실도 이해하고 있어야 한다.

 

 

 

결론

 

-

어느 클래스를 묶어서 컴포넌트로 만들지를 결정할 때, 재사용성과 개발 가능성이라는 상충하는 힘을 반드시 고려해야 한다.

이들 사이에서 앱의 요구에 맞게 균형을 잡는 일은 중요하다.

심지어 이 균형점은 거의 항상 유동적이다.