의존도와 결합도

1. 의존 역전 원칙 (DIP)과 결합도

만약 컴퓨터가 특정 키보드 클래스를 직접 생성해서 쓰면 '강한 결합'이라고 할 수 있다. 입력 장치를 바꾸고 싶을 때 컴퓨터 생성자 코드를 다 뜯어고쳐야 하기 때문이다.

이런 상황을 만들지 않기 위해 입력 장치를 '인터페이스'로 따로 구현한다.

컴퓨터에는 공통된 get_input 메서드만 노출하고, 실제 기기(키보드, 마우스 등)는 그 인터페이스를 구현하게 하는 것이다.

이렇게 하면 컴퓨터는 어떤 장치가 들어오든 상관없이 자기 코드를 유지할 수 있다.

생성할 때 다형성을 이용해서 필요한 장치를 동적으로 연결해주면 되기 때문이다.

2. 결합도(Coupling)

결합도는 모듈 간 의존하는 정도를 표현하는 척도로, 낮을수록 좋다.

 

1) 데이터 결합도(Data Coupling)

가장 좋은 형태라고 할 수 있다. 기본 자료형 데이터만 인수로 주고받는다.

예를 들자면 주차 요금을 계산할 때 '주차 시간'의 단순한 변수만 넘겨주는 경우가 해당된다.

 

2) 스탬프 결합도(Stamp Coupling)

데이터 결합도처럼 자료형 몇 개가 아니라 배열이나 객체(구조체)를 통째로 넘기는 경우이다.

넘겨받은 모듈에서 그 객체의 전체 구조를 알아야 하니까 데이터 결합도보다는 조금 더 엮여 있는 상태라 할 수 있다.

 

3) 제어 결합도(Control Coupling)

한 모듈이 다른 모듈의 내부 흐름을 제어하는 데이터를 보내는 정도의 결합이다.

"회원이면 할인해라" 등과 같은 제어 신호를 보내면, 받는 쪽 로직이 보내는 쪽에 의존하게 돼서 캡슐화가 깨진다.

 

4) 외부 결합도(External Coupling)

별개의 두 모듈이 외부의 어떤 모듈이나 라이브러리를 공통으로 참조할 때 발생한다.

이 경우 외부 라이브러리가 바뀌면 구현한 코드의 두 군데가 동시에 깨질 수 있어서 관리가 까다로워진다.

 

5) 공통 결합도(Common Coupling)

전역 변수를 공유하는 경우이다.

누가 언제 값을 바꿨는지 추적하기가 너무 힘들어서 가급적 쓰지 말아야한다.

 

6) 내용 결합도(Content Coupling)

최악의 결합도로 평가된다.

한 모듈이 다른 모듈의 내부 데이터나 기능을 직접 접근해 참조하고 수정하는 경우이다.

유지보수가 정말로 어려워진다.

3. 응집도(Cohesion)

모듈 내부가 얼마나 단단하게 뭉쳐있는지를 표현하는 척도로, 높을수록 좋다.

 

1) 기능적 응집도(Functional)

모듈 안의 모든 요소가 단 하나의 목적(을 위해서만 존재하는 상태이다.

예를 들면 스택의 구현에서 push/pop 등 관련 함수만 클래스 내부에 존재하게 하는 상황이 이 응집도이다.

 

2) 순차적 응집도(Sequential)

한 활동의 출력값이 다음 활동의 입력값으로 쓰이는 식의 흐름이 있는 경우이다.

 

3) 교환적 응집도(Communicational)

동일한 입력과 출력을 사용하면서 서로 다른 기능을 수행하는 요소들이 모여 있는 경우이다.

 

4) 절차적 응집도(Procedural)

모듈 안의 요소들이 순차적으로 실행되긴 하지만, 서로 데이터 전달은 없는 상태로 연관이 적은 형태이다.

 

5) 시간적 응집도(Temporal)

초기화 시점 등 특정 시간에 같이 실행되어야 하는 것들을 묶어놓은 것이다.

실행시간이 동일하다는 것을 제외하면 실행되는 함수들간에는 대단한 공통점이 없다.

 

6) 논리적 응집도(Logical)

논리적으로 비슷해 보이는 기능들을 묶어놓은 것으로, 내부적으로 switch문 같은 게 길게 들어가는 경우가 많다.

 

7) 우연적 응집도(Coincidental)

아무 상관 없는 기능들을 하나의 모듈에 다 때려 넣은(...) 안타까운 경우이다.

 

결론 

유지보수를 위해서는 결합도는 낮추고 응집도는 높이는 방향으로 코드를 설계해야한다.

특히 Switch문 등 복잡한 조건문은 전략 패턴(Strategy Pattern) 등을 통해 제거하는 것이 좋다.