정의의 의존성과 순환 의존성을 최소화하라

  지나치게 의존적인 것은 좋지 않다. 정의 내용을 #include 하여 의존하게 되는 상황을 줄여야 한다. 상호 의존적인 것도 피해야 한다. 순환 의존성은 두 모듈이 직/간접적으로 서로에게 의존하고 있을 때 발명하는데, 모듈은 기능이 응집된 단위이기 때문에 서로 의존하는 모듈은 진정한 개별 모듈이라 볼 수 없으며, 오히려 하나의 커다란 모듈로 보는 것이 옳다.

 

즉, 순환 의존성은 모듈의 장점에 위배되는 것으로, 큰 프로젝트에서 피해야 할 부분이다.

 

타입의 정의가 절실히 필요한 경우가 아니라면 일방적으로 방향으로의 선언을 사용하는 것이 좋다. 클래스 C의 완전한 정의가 필요한 두 가지 경우를 보자.

 

• C 개체의 크기를 알아야 할 경우
  e.g. 스택에 C를 할당할 때나 다른 타입과 직접적으로 연결된 멤버로 사용될 경우
• C의 멤버에 이름을 매기거나 호출해야 할 경우
  e.g. 멤버 함수를 호출해야 할 경우

일반적으로 의존성과 사이클 모듈 수준에서 생각할 문제이다. 모듈은 클래스와 함수들의 집합이며, 순환 의존성의 가장 간단한 형태는 다음과 같이 두 클래스가 서로를 직접적으로 의존하고 있는 경우이다.

 

class child;
class Parent {
    child* myChild_;
};

class child {
    Parent* myParent_;
};

 

  이 코드에서 parent와 child는 서로 연결되어 있다. 일단 컴파일에는 문제가 없지만, 기본적으로 불안을 안고 있다.

이렇게 서로 의존하고 있는 클래스는 같은 모듈 내에 있어야 하기 때문이다. 이러한 의존 사이클이 여러 모듈에 걸쳐 있을 대에는 상황이 더욱 악화된다. 결국 이러한 모든 모듈은 결합하여 하나의 큰 모듈을 이룰 수밖에 없고, 이는 모듈의 기본적인 특성 자체에 해를 끼치는 방식이 된다.

 이러한 사이클을 피하기 위해서는 저수준 모듈에 의존하는 고수준 모듈을 만들지 말고, 양쪽 모두 추상체에 의존하게끔 하는 것이다. Parent와 child 모두에 대해서 독립적인 추상 클래스를 만들 수 있다면 사이클을 깨뜨릴 수 있기 때문이다. 만약 그럴 수 없다면 결국 둘을 합쳐서 하나의 모듈로 만들어야 한다.

 

 이밖에도 한 클래스로부터 얻어진 클래스의 임시적인 의존성도 디자인에 악영향을 미치는 요소 중 하나이다. 이런 경우는 직접적이든 간접적이든 간에 기본 클래스로부터 대부분의 특성을 물려받기 때문이다. 적절치 않은 의존성으로 인한 첫 번째 증상은 빌드 시간과 규모가 점차 커진다는 것이다. 작은 변화에도 프로젝트 전체에 미치는 영향이 커지기 때문이다.