Component
이전에 말한 SOLID원칙들은 모두 코드 뭉텅이, 클래스 내부의 구현 방법들에 대한 방법이었다.
저자가 말하기를 벽돌에 관련한 이야기 였다면 이번에는 벽돌들을 쌓아 방의 구조를 설계하는 수준의 컴포넌트에 관련한 내용들을 다룬다고 한다.
"컴포넌트는 배포를 할 수 있는 가장 작은 단위"
Component Cohesion
컴포넌트의 응집도란 클래스를 어떤 컴포넌트를 생성하고 배치해서 나눌지에 대한 3가지 원칙을 정리한다.
Reuse/Release Equivalence Principle (REP)
: 재사용 단위는 릴리즈의 단위와 같다.
하나의 기준으로 묶인 클래스는 한개의 버전을 가지고 있어야 하며, 동일한 릴리즈 문서에 있어야한다.
우리의 기준으로 보면 한개의 깃 레포지토리로 볼 수 있을 것 같다.
뭐 지금 우리에게 생각하면 뭐 그런 당연한 이야기를 해? 라고 할 수 있지만
지켜지지 않을 경우에 대해서는 문제가 생겨 원칙이라고 저자는 말한다.
Common Closure Principle
: 동일한 이유로 동일한 시점에 변경되는 클래스를 같은 컴포넌트로 묶어야한다.
해당 원칙의 목적은 유지보수 성이다.
변경의 여지가 있는 클래스는 한 군데에 변경의 여지가 없는 불변의 클래스는 또 다른 컴포넌트로 위험성을 나누고자하는 것이 목표이다.
어디서 들어본 개념이 아닌가?
코드에서 해당하는 SRP(단일책임원칙)이 한가지의 이유 한가지의 책임을 가지는 것으로 묶어야한다고 이야기했다.
또 OCP(개방폐쇄원칙) 변경이 가능한 것과 불가능한 것의 구분하여 묶어야한다고 이야기했다.
CCP는 컴포넌트 차원에서의 위 원칙을 정의하는 것 같다.
Common Reuse Principle (CRP)
: 사용자들이 필요하지 않은 것에 의존하지 않도록 해야한다.
사실 해당 원칙도 SOLID의 ISP(인터페이스분리원칙)과 대칭되는 개념이다.
A컴포넌트에서 B컴포넌트를 의존한다고 하자.
B컴포넌트에서 변경이 일어날 경우 A컴포넌트에서도 변경사항이 발생할 수 있으며 이는 즉 위험요소가 발생할 수 있다는 의미이다.
그러므로 지난 LSP에서도 해당 기능들을 분리해 필요한 기능들에게만 의존할 수 있도록 하자라는 의미를 가졌었다.
컴포넌트에서도 이와 비슷하다. CRP는 컴포넌트 간에 의존성이 발생할 때, 의존하는 컴포넌트의 모든 기능들이 필요한가? 에 대해서 고민해보고 필요가 없다면 분리해야한다는 의미이다.
The Tension Diagram for Component Cohesion
: 컴포넌트 응집도에 대한 균형 다이어그램.
REP와 CCP 원칙은 두 컴포넌트를 어떻게 합쳐야 할지에 대한 고민거리들
CRP는 컴포넌트를 어떻게 분리해야 할 지를 고민할 수 있게 해주는 원칙들이다.
이 원칙들을 잘 고민하여 균형있게 컴포넌트들의 구조들을 가져가는 것이 좋은 코드를 만들 것이라는 이야기를 한다.
또한 해당 구조들은 프로젝트의 상태에 따라 변화한다고 이야기한다.
프로젝트가 태동되는 시기에는 재사용성에 대해서 고민을 하게 되며, 프로젝트가 점점 발전하는 시기에는 유지보수성에 대에서 더 고민하여 움직이게 된다.
결국은 그 때에 따라 어떻게 균형있게 가져갈지를 고민해 더 중점을 두어 컴포넌트를 구상해야한다고 이야기한다.
Component Coupling
Acyclic Dependencies Principle (ADP)
: 의존성 비순환 원칙
컴포넌트 간의 관계에 있어서 항상 순환이 끊어져야만 한다.
기본적인 컨셉은 컴포넌트를 분리해 최소한의 릴리즈 가능한 단위로 구현.
그러나 위의 그래프를 보면 Interactors, Authorizer, Entities 가 서로 순환해 구현이 되고 있는데, 이렇다면 컴포넌트를 나눈다 한들 저들 중 한가지를 수정하기 위해선 3번의 릴리즈가 필요한 구조가 되며, 컴포넌트화를 하느니 못한 상황이 발생한다.
이때, 비효율적인 순환을 해결하기 위해 DIP에 사용된 방식이 적용이 된다.
이전과 같이 인터페이스 역할을 하는 Permissions라는 컴포넌트를 만들어 의존성을 역전시켜 순환의 고리를 해결한다고 한다.
Stable Dependencies Principle (SDP)
: 안정된 의존성 원칙
변동성이 높은 컴포넌트를 의존하지 않도록 관계를 가지는 것.
이곳에선 변동성이 낮은 것은 안정성이 높다고 표현하며, 쉽게 변할 수 있는 것은 안정성이 낮다고 표현한다.
그리고 안정성이 높은 것에 의존할 수 있도록 컴포넌트를 설계하라는 의미로 이전에 OCP의 컴포넌트 관계 버전이 아닐까 생각된다.
Stable Abstractions Principle(SAP)
컴포넌트는 안정된 정도만큼만 추상화되어야 한다.
사실 Class 수준의 DIP의 관계에서는 완전히 추상적이거나 완전히 구체적이거나 둘 중 하나의 경우를 따를 수 있었다.
하지만 컴포넌트 수준에서는 명확히 이를 나누기란 쉽지 않은 것이다.
이에 대한 솔루션으로 추상화 정도를 측정을 해.
변동이 가능한 컴포넌트는 안정도와 추상도를 고려해 두 균형을 이루는 수준에서 구현해 유동적으로 대응 할 수 있어야 한다고 이야기 한다.
결론
기존엔 컴포넌트 수준의 고민을 실제로 해본 적이 없어 슬슬 책의 내용이 나에겐 추상의 영역으로 넘어온 듯한 이야기들이었다.
실제 구현에서는 안드로이드 앱과 iOS 앱이 관계를 가질 일도. 서버와 앱이 관계를 가질 일은 API 정도 밖에 없을 것이다.
아마 추후에 우리 서비스를 고도화 시켜 한 앱 내부에 큰 규모에서 여러 컴포넌트를 다룰 일이 생길 때 다시 펼쳐볼지 모르겠다.
크게 느낀 컨셉에선 이전에 다루었던 디자인 원칙과 크게 다르지 않았다.
변하지 않는 것과 변하는 것들을 쪼개고 서로가 서로에게 영향을 미치는 영향이 적을 수 있도록 설계하는 것.
