아이템 18 상속보다는 컴포지션을 사용하라

상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다.
상위 클래스와 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서라면 상속도 안전한 방법이다. 확장할 목적으로 설계되었고 문서화도 잘 된 클래스(아이템 19)도 마찬가지로 안전하다. 하지만 일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일은 위험하다.
메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 상위 클래스는 릴리스마다 내부 구현이 달라질 수 있으며, 그 여파로 코드 한 줄 건드리지 않은 하위 클래스가 오동작할 수 있다는 말이다

상속을 잘못 사용한 케이스

public class InstrumentedHashSet<E> extends HashSet<E> {

    // 추가된 원소의 수
    private int addCount = 0;

    public InstrumentedHashSet() {
    }

    public InstrumentedHashSet(int initCap, float loadFactor) {
        super(initCap, loadFactor);
    }

    @Override
    public boolean add(E e) {
        addCount++;
        return super.add(e);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }

    public int getAddCount() {
        return addCount;
    }
}

위 코드 베이스에서 아래 코드를 실행하는 경우 잘못된 결과가 출력된다.

InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
s.addAll(List.of("틱", "탁탁", "펑"));

s.의 size는 3을 예상하지만 실행시켜보면 6이 나온다.
InstrumentedHashSet addAll()의 내부에서 addCount를 더하고 super.addAll(c) 로 HashSet의 메서드를 호출했다. HashSet의 addAll()은 add()를 매번 호출하는 방식으로 구현되어 있는데, InstrumentedHashSet의 add()에 addCount++ 연산이 있기 때문에 크기가 2배로 나온 것이다.

이 처럼 자신의 다른 부분을 사용하는 부분은 해당 클래스의 내부 구현 방식에 의존할 수 밖에 없다. InstrumentedHashSet는 깨지시 쉬운 클래스인 것이다.
또한 HashSet에 새로운 메서드가 추가됐을 때, InstrumentedHashSet가 이를 적절히 override 하지 못했다면 보안 취약점이 될 수도 있다.

해결책은 구성(Composition)이다!

기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하자.

public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;
    public InstrumentedSet(Set<E> s) {
        super(s);
    }
    @Override public boolean add(E e) {
        addCount++;
        return super.add(e);
    }
    @Override public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);
    }
    public int getAddCount() {
        return addCount;
    }
}

public class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;
    public ForwardingSet(Set<E> s) { this.s = s; }
    public void clear() { s.clear(); }
    public boolean contains(Object o) { return s.contains(o); }
    public boolean isEmpty() { return s.isEmpty(); }
    public int size() { return s.size(); }
    public Iterator<E> iterator() { return s.iterator(); }
    public boolean add(E e) { return s.add(e); }
    public boolean remove(Object o) { return s.remove(o); }
    public boolean containsAll(Collection<?> c)
    { return s.containsAll(c); }
    public boolean addAll(Collection<? extends E> c)
    { return s.addAll(c); }
    public boolean removeAll(Collection<?> c)
    { return s.removeAll(c); }
    public boolean retainAll(Collection<?> c)
    { return s.retainAll(c); }
    public Object[] toArray() { return s.toArray(); }
    public <T> T[] toArray(T[] a) { return s.toArray(a); }
    @Override public boolean equals(Object o)
    { return s.equals(o); }
    @Override public int hashCode() { return s.hashCode(); }
    @Override public String toString() { return s.toString(); }
}

구체적으로 Set 인터페이스를 구현했고 Set 인스턴스를 인수로 받는 생성자를 하나 제공한다. 임의의 Set에 계측 기능을 덧씌워 새로운 Set으로 만드는 것이 이 클래스의 핵심이다.
한 번만 구현해두면 어떠한 Set 구현체라도 함께 사용할 수 있다.

다른 Set 인스턴스를 감싸고(wrap) 있다는 뜻에서 InstrumentedSet 같은 클래스를 래퍼 클래스라 하며, 다른 Set에 계측 기능을 덧씌운다는 뜻에서 데코레이터 패턴(Decorator pattern)이라고 한다. 컴포지션과 전달의 조합은 넓은 의미로 위임(delegation)이라고 부른다. 단, 엄밀히 따지면 래퍼 객체가 내부 객체에 자기 자신의 참조를 넘기는 경우만 위임에 해당한다.
래퍼 클래스가 콜백 프레임워크와는 어울리지 않는다는 점을 주의하자. 내부 객체는 외부의 존재를 모르고 자신의 참조를 넘기게 되면 콜백때는 래퍼가 아닌 내부 객체를 호출하게 된다. 이를 self 문제라고 한다.

음 그럼 상속은 언제 사용하지?

상속은 반드시 하위 클래스가 상위 클래스의 ‘진짜’ 하위 타입인 상황에서만 쓰여야 한다. 다르게 말하면, 클래스 B가 클래스 A와 is-a 관계일 때만 클래스 A를 상속해야 한다.
컴포지션을 써야 할 상황에서 상속을 사용하는 건 내부 구현을 불필요하게 노출하는 꼴이다. 그 결과 API가 내부 구현에 묶이고 그 클래스의 성능도 영원히 제한된다. 더 심각한 문제는 클라이언트가 노출된 내부에 직접 접근할 수 있다는 점이다.
컴포지션으로는 이런 결함을 숨기는 새로운 API를 설계할 수 있지만, 상속은 상위 클래스의 API를 ‘그 결함까지도’ 그대로 승계한다.

핵심정리

상속은 강력하지만 캡슐화를 해친다는 문제가 있다.
상속은 상위 클래스와 하위 클래스가 순수한 is-a 관계일 때만 써야 한다. is-a 관계일 때도 안심할 수만은 없는 게, 하위 클래스의 패키지가 상위 클래스와 다르고, 상위 클래스가 확장을 고려해 설계되지 않았다 면 여전히 문제가 될 수 있다.
상속의 취약점을 피하려면 상속 대신 컴포지션과 전달을 사용하자.
특히 래퍼 클래스로 구현할 적당한 인터페이스가 있다면 더욱 그렇다.
래퍼 클래스는 하위 클래스보다 견고하고 강력하다.

item 18 dodo4513 - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

아이템 18 상속보다는 컴포지션을 사용하라

상속을 잘못 사용한 케이스

해결책은 구성(Composition)이다!

음 그럼 상속은 언제 사용하지?

핵심정리

⚠️ GitHub.com Fallback ⚠️

item 18 dodo4513 - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

아이템 18 상속보다는 컴포지션을 사용하라

상속을 잘못 사용한 케이스

해결책은 구성(Composition)이다!

음 그럼 상속은 언제 사용하지?

핵심정리

⚠️ **GitHub.com Fallback** ⚠️

⚠️ GitHub.com Fallback ⚠️