작년 12월의 semtlnori와의 대화중에 “내가 cohesion에 대해 오해를 했군”이라는 단편조각을 토대로 거의 6개월 이상 캘린더 TODO리스트에 있던 응집도 오해라는 주제를 정리해보려고 한다.

첫번째 오해 - 응집도의 정의

응집도에 대한 첫번째 오해는, 응집도라함이 적절한 구성요소들이 적절하게 모여있는것이라고 생각한 정의적인 오해였다. 이것은 사실 응집도의 문맥에 매우 맞아 보였지만 이 정의에 의해 생각한 좋은 응집도를 가진 객체에 있어서 핵심적인 오해를 불러 일으켰다.

두번째 오해 - 좋은 응집도를 가진 객체

적절히 모여 있어야 함은 사실 응집도를 가진 객체라고 판단하는데 잘못된 생각을 가지게 했는데, 1가지 메소드만을 가진 객체 (혹은 인터페이스)를 적절히 모여 있지 못한 객체라고 인지하게 만들었다! 하나의 속성만을 나타내는 객체가 속성들을 모아야 하는 응집도의 특성에 어긋난다고 생각했던 것이다. 따라서 최근 함수형 언어적 합성성을 취하기 위해 많이 생기고 있는 SAM 유형들은 객체를 설명하기 위한 속성들이 적절히 모여있지 않기 때문에 응집도 측면에서는 좋지 못한 설계들이라고 생각했다.

응집도 - 전체와 부분

컴퓨터 과학에서 응집도는 모듈에 해당하는 전체개념과 요소에 해당하는 부분개념이 존재한다. 첫번째 오해를 모듈과 개념으로 다시 말해보면

좋은 응집도를 가진 모듈은 적절히 정의된 모듈의 속성과 성질을 잘 들어내는 요소들로 구성된 모듈 (주의 - 오해임)

라고 할수 있다. 그러나 사실 응집도에 대한 정의는

좋은 응집도를 가진 모듈은 서로 상관있는 요소들로 구성되어 있는 모듈

쯤이라 할 수 있다. 이러한 정의는

라는 일반화된 공식으로 표현될 수 있다.

높은 응집도를 가지기 위해

모듈과 요소는 매우 여러 레벨에서 사용될 수 있어서 실제적인 응집도 측정을 하기에는 좀더 세밀한 정의가 필요하다 - 무엇의 응집도를 젤것인지, 관계가 있는 요소라 함은 무엇인지 등등..

LCOM4는 Class의 응집도를 측정하는 방법중 가장 널리 쓰이는 방법인데,

• 모듈 레벨은 Class
• 요소를 Field와 Method로 나눔
• Method a내에서 다른 Method b를 호출하면 a와 b는 관계가 있음
• Method a내에서 Field b를 읽거나 쓰면 a와 b는 관계가 있음
• 관계가 있는 요소들을 연결했을때 연결되지 않는 요소 집합의 수를 측정

정도로 요약할수 있고, 높은 응집도의 클래스는 모든 요소들이 연결되어 있어서 LCOM4 값이 1이 된다.

자세한 설명은 http://www.aivosto.com/project/help/pm-oo-cohesion.html 사이트를 참조하는것이 좋들듯 하다. (위의 이미지도 해당 사이트에서 발췌하였다)