Component Refactoring [5]

구현 컴포넌트 분석 - 컴포넌트 크기 분석

컴포넌트는 적절한 크기로 만들어져야 하며, 그 크기는 상대적으로 관리할 수 있는 형태이어야 한다. 즉, 컴포넌트는 독립적인 비즈니스 개념 및 프로세스를 담고 있어야 한다. 컴포넌트 크기는 인터페이스 갯수, 인터페이스의 오퍼레이션 갯수, 컴포넌트가 호출하는 다른 컴포넌트의 인터페이스 갯수 등 다양한 기준으로 측정이 가능하며, 각각의 경우에 있어서 적절한 기준을 선정해야 한다.

유형
- 하나의 컴포넌트가 너무 많은 인터페이스를 가지고 있는 현상.
- 하나의 인터페이스에 서로 성격이 다른 유형의 오퍼레이션을 가지고 있는 현상.
- 하나의 오퍼레이션이 너무 많은 기능을 수행하는 현상.
- 하나의 인터페이스가 너무 적은 수의 오퍼레이션을 가지고 있는 현상.

분석 내용

- 컴포넌트가 가지고 있는 인터페이스, 인터페이스의 오퍼레이션, 클래스의 수 등을 측정하여 컴포넌트가 해당 수치를 비교.
- 하나의 컴포넌트가 2 ~ 3 명의 개발자가 개발 가능한지를 측정.
- 컴포넌트가 호출하는 인터페이스 개수 측정 및 비교.
- 해당 컴포넌트를 호출하는 컴포넌트의 개수 측정 및 비교.

위의 그림에서 1번의 경우, 너무 많은 인터페이스를 갖는 경우로, 하나의 컴포넌트에 너무 많은 기능들이 몰려있는 상태로, 적절한 크기의 책임을 가지는 컴포넌트로 분화를 할 필요가 있다. 컴포넌트를 분화할 경우, 컴포넌트 내부의 객체들도 같이 분석하여 유사성이 있는 객체들로 같이 묶어서 컴포넌트 간의 커플링을 최소한으로 하고, 내부 객체의 결속력을 높이는 방향으로 분화해야 한다.
2번의 경우는 하나의 인터페이스에 너무 많은 오퍼레이션이 있는 경우로 유사성이 많은 오퍼레이션이 발생되는 경우가 대부분이다. 즉, 기능을 너무 세분화하여 나누게 되면 기능(서비스)의 양이 많아지는 대신에 제공하는 기능(서비스)의 크기 자체가 너무 작아지는 경향이 있다. 이러한 경우에는 해당 기능의 통폐합을 생각해볼 수 있다. 이 경우는 인터페이스의 추상화 수준을 높이는 방향으로 하나의 오퍼레이션에서 조그마한 기능보다는 좀 더 큰 기능을 수행할 수 있게 해야 한다. 또한, 이와 같은 경우에 인터페이스 기능에 대한 표준화를 생각해볼 수 있다. 기능의 표준화는 불필요한 기능을 없애고 기존의 기능으로 통합할 수 있는 여지를 제공하게 된다. 인터페이스/오퍼레이션 식별은 비즈니스와 깊은 연관관계가 있으므로 비즈니스와 연계해서 항상 고려해야 한다.
3번은 독립적으로 의존관계가 없이 별도로 떨어져 있는 컴포넌트인데, 이 경우에도 기능의 연관성이 없다는 비즈니스의 요구사항을 무시하면서 일부러 조정할 필요까지는 없지만, 이러한 컴포넌트들이 많아진다면, 왜 그런 의존관계들이 형성되었는지를 먼저 파악을 해야 한다. 예를 들어, 독립적인 어플리케이션으로 분류할 수 있는데, 비즈니스의 조정이 이루어지지 않은 상태에서 구현되었을 수도 있다. 이러한 상태는 비즈니스를 다시 조정함으로써 독립된 컴포넌트들을 별도로 구획화하는 노력이 별도로 필요할 수도 있다.