장기적으로 볼 때, 상속은 해결한 것보다 더 많은 문제를 야기했다. 다중 상속이 그중 하나이다. 만약 여러분이 여러 클래스의 코드를 재사용해야 하고, 모든 클래스가 같은 이름의 메서드를 가지고 있다면 어떨까? 같은 서명을 가지고 있다면 어떻게 동작할까? 그림 3-9의 다이아몬드 종속성 문제는 어떤가? 이는 정말 복잡해서 극소수의 프로그래밍 언어로만 구현이 가능했다.

다중 상속보다 더 큰 문제는 강한 결합(tight coupling)이라고도 알려진 강한 종속성이었다. 앞에서 다루었듯이, 종속성은 모든 악의 근원이다. 상속의 고유한 특성 때문에 어떤 구체적인 구현에 얽매이게 되는데, 이것은 객체 지향 프로그래밍의 잘 알려진 원칙 중 하나를 위반하는 것으로 간주된다. 바로 종속성 역전 원칙(dependency inversion principle)의 위반이다. 종속성 역전 원칙은 코드가 이러한 구체적인 구현에 절대 의존해서는 안 된다고 명시한다.

왜 이런 원칙이 있는 걸까? 구체적인 구현에 얽매이게 되면 코드가 경직되기 때문이다. 앞서 봤듯이, 경직된 코드는 테스트하거나 수정하기가 매우 어렵다.

그럼 코드를 어떻게 재사용해야 할까? 추상화에서 어떻게 클래스를 물려 받을까? 간단하다. 합성(composition)을 사용하면 된다. 클래스에서 상속받는 대신 생성자에서 매개변수로 추상화를 받는다. 구성 요소를 객체의 계층 구조라기보다는 서로를 지지하는 레고 조각으로 생각하라.

보통의 상속에서는 일반적인 코드와 그 변형 사이의 관계를 부모-자식 모델로 표현한다. 이와 대조적으로 합성은 공통 함수를 별도의 구성 요소로 생각한다.