상호의존성은 모델과 설계를 이해하기 어렵게 만든다. 또한 테스트를 어렵게 만들고 유지보수성을 떨어트린다.
모든 연관관계는 의존성을 의미하므로 클래스를 이해하려면 연관관계를 토대로 어떤 요소가 연결돼 있는지 이해해야 한다.
이러한 요소는 또 다른 요소와 연관돼 있으므로 이들 역시 이해하고 있어야 한다. 모든 메서드에 포함된 인자 타입 역시 의존성을 의미한다. 이것은 메서드의 반환 타입에 대해서도 마찬가지다.
의존성이 하나만 있더라도 동시에 두 개의 클래스를 고려해야 하고 그 관계의 본질에 관해 생각해야 한다. 두 개의 의존성이 존재한다면 동시에 세 개의 클래스를 고려해야 하고, 클래스 간의 관계에 내포된 본질과 의존성 간에 존재할지도 모르는 관계에 대해서도 생각해야 한다.
의존성이 많아질수록 경계해야 할 부분들이 눈덩이처럼 불어난다.
MODULE
과 AGGREGATE
모두 지나치게 얽히고 설키는 상호의존성을 방지하는 것이 목적이다.
MODULE
내에서조차 의존성이 증가할수록 설계를 파악하는 데 따르는 어려움이 가파르게 높아진다. 이는 개발자에게 정신적 과부하를 줘서 개발자가 다룰 수 있는 설계의 복잡도를 제한한다.
아울러 명시적인 참조에 비해 암시적인 개념이 훨씬 더 많은 정신적 과부하를 초래한다.
정제된 모델은 여러 개념 간에 남은 모든 연결이 해당 개념의 의미에 근본적인 뭔가를 나타낼까지 증류된다.
중요 부분집합에서는 의존성의 수가 0으로 줄어들 수 있으며, 그 결과 몇 가지 기본적인 기능과 기본 라이브러리 개념과 함께 그 자체로도 완전히 이해할 수 있는 클래스가 만들어진다.
낮은 결합도는 객체 설계의 기본 원리다. 가능한 한 늘 결합도를 낮추고자 노력해야 한다.
현재 상황과 무관한 모든 개념을 제거해야 한다. 그러면 클래스가 완전히 독립적(self-contained)으로 바뀌고 단독으로 검토하고 이해할 수 있을 것이다.
독립적인 클래스는 MODULE
을 이해하는 데 따르는 부담을 상당히 덜어준다.
모든 의존성을 제거하는 것이 아니라, 비본질적인 의존성을 제거하는 것이 목표다.
의존성의 제거가 제멋대로 모델에 포함된 모든 요소를 원시 타입으로 격하시키는 것을 의미하지는 않는다.
가장 복잡다단한 계산을 STANDALONE CLASS
로 도출하려고 노력하라. 이 때 VALUE OBJECT
로 모델링하고 좀 더 관계가 밀접한 클래스에서 해당 VALUE OBJECT
를 참조할 수 있다.
Product
라는 클래스에서 금액적인 부분을 계산하는 것을 AmountCalculator
로 분리해볼 수 있음