[클래스와 인터페이스]규칙16. 계승하는 대신 구성하라

 계승은 코드 재사용을 돕는 강력한 도구지만, 항상 최선이라고는 할 수 없다. 그리고 해당 클래스가 속한 패키지 밖에서 계승을 시도하는 것은 위험하다. 왜냐하면 메서드 호출과 달리 계승은 캡슐화 원칙을 위반하기 때문이다. 

 예를들어, 하위 클래스가 정상 동작하기 위해서는 상위 클래스의 구현에 의존할 수 밖에 없다. 상위 클래스의 구현은 릴리즈가 거듭되면서 바뀔 수 있는데 이러한 과정속에서 하위클래스의 코드는 수정된 적이 없어도 망가질 수 있다. (캡슐화 원칙 위반)

 이러한 문제를 해결하귀 위해서는 기존 클래스를 계승하는 대신, 새로운 클래스에 기존 클래스 객체를 참조하는 private 필드를 하나 두는 것이다. 이런 설계 방법을 구성이라고 한다.

public class InstrumentedSet<E> extends ForwardingSet<E>{ private int addCount = 0; public InstrumentedSet(Set<E> e){ super(s) } @Override public boolean add(E e){ addCount+=; return super.add(e); } @Override ... } public class ForwardingSet<E> implements Set<E>{ private final Set<E> s ; public ForwardingSet(Set<E> s) { this.s = s ; } public void add(E e) { return s.add(e); } ... ... }

 계승 매커니즘은 상위 클래스의 문제를 하위 클래스에 전파시킨다. 반면 구성 기법은 그런 약점을 감추는 새로운 API를 설계할 수 있다.

계승은 어떠한 경우에 사용해야 할까?

계승은 하위클래스가 상위 클래스의 하위 자료형이 확실한 경우에만 바람직하다. 다시 말해서, 클래스 B는 클래스 A와 "IS-A" 관계가 성립할 때만 A를 계승해야 한다.