[클린아키텍처] 컴포넌트 응집도의 3가지 원칙 (REP, CCP, CRP)

컴포넌트 응집도의 3가지 원칙 (REP, CCP, CRP)

안녕하세요 이웃님들~

요즘 클린 아키텍처를 읽어보고 있는데요~!

평소 많이 보는 SOLID 원칙은 인터넷 상에 자료가 많으니

컴포넌트 응집도 3가지 원칙인 REP, CCP, CRP를 정리해 보려고 합니다~!!!

 

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

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

컴포넌트가 릴리스 절차를 통해 추적 관리가 되고, 릴리스 번호가 부여되어야 한다는 원칙입니다. 그래야 컴포넌트의 사용자인 개발자가 이 컴포넌트를 계속 재사용 할지 여부를 결정할 수 있게 된다는 것 인데요.

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

책에서도 당연한 얘기 아니냐고 하지만, 당연한 이 원칙이 지켜지지 않으면 컴포넌트를 사용하는 것이 사용자 입장에서 꺼려지겠죠! 

 

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

 

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

이 원칙의 설명을 딱 들어보면 뭔가... 단일 책임 원칙(SRP)가 생각 나지 않나요? 단일한 클래스는 변경의 이유가 한 곳에서만 발생을 해야한다는 것이 단일 책임의 원칙에 나오는데요..! 그것의 컴포넌트 버전의 원칙이 CCP 라고 합니다. 

REP가 재사용에 관한 원칙이라면 CCP는 유지보수에 관련된 원칙인데요! 유지보수를 할때 가장 문제되는게 어디서 변경이 일어나서 여기저기 사이드가 나는거겠죠... 그래서 변경이 한곳에서 일어나면 여기저기 고쳐야 되기 보다는 한 곳만 그 변경에 영향권에 있는게 유지보수 면에서 좋겠죠! 또한 다른 컴포넌트까지 다 배포 할 필요 없이 변경점이 생긴곳만 배포 하면 된다는 장점도 있겠습니다. 

 

그래서 같은 이유로 변경이 될 만한 클래스들은 묶어서 컴포넌트로 관리해주어야 한다고 합니다. 

 

마찬가지로 개방 폐쇄의 원칙(OCP)가 생각이 나는데요! 이런 변경이 일어날 때 (물론 가능하면 확장을 하고 변경을 안하면 좋겠지만) 불가피하게 변경을 해야한다고 하더라도 변경의 영향범위가 한정되어 있으니 더욱 안정적으로 운영이 가능하도록 설계하는 것이라고 하네요.

 

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

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

같이 재사용이 되는 경향이 있는 클래스와 모듈들은 같은 컴포넌트에 포함 되어야 한다는 원칙인데요.

이런 원칙들은 뭐를 해라~ 보다 하지말아라를 잘 봐야되겠죠..?

 

단 하나의 클래스만을 사용하기 위해서 하나의 컴포넌트로 묶어버리면 이미 의존성이 생겨버린 상태에서 하나의 클래스를 쓰더라도 사용하는 컴포넌트가 변경될때마다 의존성을 가지는 다른 컴포넌트로 바꿔줘야 하는 상황이 생길 수 있어요. 그래서 결합이 아주 강해야 하는 경우를 제외하면 단일 컴포넌트로 묶는 것을 경계해야 한다고 합니다.