[설계 용어] 응집도(Cohesion)와 결합도(Coupling)
High Cohesion, Low Coupling, 응집도와 결합도 라는 설계관련 용어는 프로그래밍에 익숙하지 않은 사람들에게는 쉽게 익숙해지기가 처음에는 어려울 것 같아요.
좋은 설계를 하기위해 고민할 때 이 용어들에 대해서도 한번 알아보시면 좋을 것 같습니다.
설계하는 것에 정답은 없겠지만.. 일반적으로 좋은 설계는 유지보수를 용이하게 해주는 설계가 좋은 설계 일 것이라 생각됩니다. 그런면에서 좋은 설계는 높은 응집도와 낮은 결합도를 가지도록 구성하게 하도록 배치하는 것이라고 생각되네요.
높은 응집도? 낮은 결합도? ….???!
이 용어에 대해 이해해 보죠.. 그 전에 자주 언급하는 모듈이란 단어에 대해 먼저 적어볼께요.
모듈
모듈(module)이라는 개념이 명확하게 존재하지는 않는 것 같아요.
여기서 모듈이란 크기와 상관없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미하겠습니다.
참고로 클린 소프트웨어 저자인 로버트 마틴에 따르면 모든 모듈은 1. 제대로 실행되어야 하고, 2.변경이 용이해야되고, 3. 이해하기 쉬워야 한다고 합니다.
응집도
응집도Cohesion는 모듈에 포함된 내부 요소들이 하나의 책임/ 목적을 위해 연결되어있는 연관된 정도 입니다.
- 모듈이 하나의 목적을 수행하는 요소들간의 연관성 척도
- 모듈 내부의 기능적인 응집 정도를 나타냄
- 높을 수록 좋아요 ❤️
- 하나의 모듈(A 모듈)에 하나의 책임/ 목적을 위해 연결(a 기능들)이 잘 모여있는 것과 아닌 경우 수정하기가 어느쪽이 어려울까요?
유지보수를 위해 a 라는 기능을 수정하기 위해 a 기능이 모여있는 A 모듈만 찾아서 수정하면 편할것같아요.
그런데 A모듈이 아닌 곳에 a 기능 들이 흩어져 있다던가 또는 A 모듈에 a 기능 외에 b, c, d 기능들도 섞여서 복잡하게 구현되어 있다면 수정하기가 힘들겠죠.
A 모듈 안에 a 라는 기능을 위해 모여있고 긴밀하게 연결되어 협력하고 있다면 그 모듈은 높은 응집도를 가진다 할 수 있습니다. 그 반대로 서로 다른 목적을 가지고 있거나 흩어져 있다면 낮은 응집도를 가진다 할 수있습니다.
응집도가 높으면, 변경 대상과 범위가 명확해지는 장점이 있어서 코드를 수정하기 쉬워집니다.
결합도
결합도 Coupling는 다른 모듈과의 의존성이 정도 입니다. 모듈 수정을 위해 다른 모듈의 변경을 요구하는 정도 로도 생각해 볼 수 있습니다.
- 모듈이 다른 모듈에 의존하는 정도의 척도
- 모듈과 모듈간의 상호 결합 정도를 나타냄
- 낮을 수록 좋아요 ❤️
유지보수를 위해 b 라는 기능을 수정하기 위해 b 기능이 모여있는 B 모듈을 수정하는 데, 다른 모듈들(A, D, E, F, I, E ) 과 기능들과 연관되어 수정하려면 다른 모듈의 소스도 확인하면서 해야됩니다. 필요 시 다른 모듈들(A, D, E, F, I, E )까지 수정해야된다면 유지보수가 더욱 힘들것입니다.
이럴때 다른 모듈과의 결합도가 높은 상황이네요.
반대로 A모듈이 다른 모듈들을 참조하는 부분이 거의 없어서 의존도가 낮은 상황이라면 유지보수가 편할 것입니다. 이렇게 참조가 적은 상황을 ‘느슨하게 연결되었다’ 표현하며 결합도가 낮은 상황이라 할 수 있네요.
결합도가 높으면 변경하고 검토해야되는 모듈 수가 많아지는 단점이 있으니, 결합도는 낮을수록 검토해야되는 소스의 수가 적어져서 코드를 수정하기가 쉬워집니다.
조금 더 깊게 생각해보기
응집도와 결합도는 좋은 설계를 학습해 가실 때 접하게 되지 않을까 싶습니다.
유지보수를 용이하게 하기 위해 구현 할 때부터 응집도는 높이고, 결합도를 낮추기 위해 고민하다보면 또 다른 개발지식을 익혀나게 될 것같네요.
응집도가 높으면 무조건 좋을까요?? 🧐
응집도가 높으면 수정해야될 코드가 한군데 모여있기 때문에 수정되는 부분을 파악하기 위해 구석구석 꼼꼼하게 소스를 찾아보지 않고 하나(최소한)의 모듈만 분석해서 수정하면 되니 (수정해야되는 부분이 단순??해져서) 유지보수 하기 좋을거에요.
- 서로 다른 코드를 하나의 모듈에 뭉쳐 놓고, 그 중 하나의 코드에 변경해야되는 상황이 발생한 경우.. 함께 존재하는 이유 만으로 모듈 내 변경할 필요없는 코드도 수정해야될 이슈가 생길 수 있습니다.
- 하나의 모듈에 수정해야될 코드가 모여있지 않고 엉뚱한 곳에도 코드가 모여있는 경우.. 한 곳에 모여있을 때 보다 복잡해(어려울 만큼 여러 가지가 얽혀) 져서 코드 수정이 더 어려울 것 같네요.
응집도가 높으면, 복잡도를 낮출 수 있는 것 같습니다.
결합도는 높으면 무조건 문제가 될까요?? 🧐🧐
변경될 가능성이 적은 모듈의 경우는 결합도가 높아도 문제가 적은 것 같습니다. 표준 라이브러리의 포함된 모듈이나 성숙 단계에 접어든 모듈에 의존하는 경우가 그러한 경우인 것 같습니다.
그렇지만 우리가 작성하고 설계한 코드는 버그나 회사에사의 갑작스러운 요구사항에 변경되기 쉽습니다.
어떻게 하면 모듈간 변화의 영향을 줄이고 의존성을 낮추고 재사용성을 높일 수 있을까 하는 고민을 통해..
낮은 결합도가 낮게 유지되도록 노력해야 될 것 같습니다.
추가적으로
두가지 응집도와 결합도를 좀 더 학문적으로 깊게 찾아보실 수도 있어요.
결합도, 응집도의 강함, 약함의 척도를 나타낸 정의도 있습니다. 찾아보시면 깊이 있게 이해하는 데 도움이 될 것 같아요.
- 응집도 (강함⬅️ ➡️약함) : 기능적, 순차적, 교환적, 절차적, 시작적(일시적) , 논리적, 우연적 응집도
- 결합도 (약함⬅️ ➡️강함) : 자료, 스탬프, 제어, 외부, 공통, 내용 결합도
추가적으로 인터페이스에 의존하는 코드 작성은 낮은 결합도를 얻을 수 있다고 합니다.
인터페이스 의존, 의존성 주입, SOLID ..
공부하시면서.. 개발하시면서.. 연관되는 키워드들은 찾아보시면 더욱 좋을 것 같아요.
마무리
당연한 이야기 였죠?
같은 책임/ 목적을 가진 기능들은 하나의 모듈에 모여있는 것이 나중에 수정(변화)하기 쉽겠죠.
모듈을 수정하려고 하는 데, 다른 모듈이 영향을 받으면 수정하기 힘들 테니, 그 영향이 거의 없다면 (느슨하다) 부담없이 수정이 가능 할테니 수정이 더 쉽겠죠
모듈 내부에 같은 책임을 가진 요소가 잘 모여있으면 응집도가 높다, 다른 모듈에 의존성이 적으면 결합도가 낮다
라고 설계 용어를 이용해서 줄여서 표현하고 있네요.
이미 응집도가 높고, 결합도가 낮은 좋은 설계(코드의 배치)를 하기위해 이미 고민하고 계실거에요.
혹시 이 용어들에 익숙하지 않으셨다면, 기억해 두시면 좋을 것 같습니다.
참조
- 책 :: 오브젝트 :: 조영호 지음
- 책 :: 클린 소프트웨어 :: 로버트 마틴 (Robert C. Martin) 지음
- 링크 : https://medium.com/@shaul1991/초보개발자-일지-소프트웨어-모듈과-모듈화-결합도-응집도의-이해-44af52e03a91
- 링크: https://yimma.tistory.com/159
- 위키링크 : https://ko.wikipedia.org/wiki/결합도
- 위키링크 : http://itwiki.kr/w/응집도
잘못된 부분이 확인되면 바로바로 수정해 두겠습니다.~
읽어주셔서 감사합니다.
즐거운 하루 되세요 🙇
