이펙티브 자바, 쉽게 정리하기 - item 18. 상속보다는 컴포지션을 사용하라

이펙티브 자바, 쉽게 정리하기 - item 18. 상속보다는 컴포지션을 사용하라

상속의 단점

여기서 이야기하는 상속은 '클래스 상속'이며, 인터페이스 상속과는 무관하다.

상속은 캡슐화를 깨뜨린다.

• 모듈을 만들 때는 객체지향 설계 원칙(SOLID)에 의해 응집도는 높고 결합도는 낮은 모듈을 만들고 변경사항이 있을 때는 클라이언트의 코드만 변경하는 것이 이상적이다.
  • 그런데, 다른 객체를 상속 받는 하위 클래스는 상위 클래스의 구현 내용 변경에 따라 하위 클래스의 구현 내용도 바뀔 수 있다.
  • 그 말은 즉, 코드 한줄 건드리지 않은 하위 클래스가 오동작할 수 있다는 것이다.
  • 이러한 방식으로 상속은 캡슐화를 깨뜨릴 수 있다.

상속에서 일어나기 쉬운 실수 1: 자기사용

static 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;
   }
}

@Test
public void instrumentHashSetTest() {
   InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
   s.addAll(List.of("A", "B", "C"));
   System.out.println("s.getAddCount() = " + s.getAddCount());
}

• 위 코드의 의도는 원소가 추가될 때마다 addCount의 수를 1씩 증가시키고 싶었다.
  • 그런데 테스트 결과 3개의 원소만 추가했는데 addCount가 6이 되었다.
• 사실 하위 클래스에서 addAll()을 재정의하지 않으면 일어나지 않을 문제이다.
  • 그러나 addAll()은 결국 add()를 이용해 구현했음을 가정한 해법이라는 한계를 지닌다.
  • 자신의 다른 부분을 사용하는 방식을 자기사용(self-use)이라고 하는데 이는 플랫폼의 전반적인 정책인지 다음 릴리즈에서 유지될지 알 수 없다.

상속에서 일어나기 쉬운 실수 2: 하위 클래스의 캡슐화가 깨져버리는 다른 경우들

• 원소를 추가하는데 특정한 제약조건이 있는 컬렉션이 있을 때 상위 클래스에 새롭게 원소를 추가하는 메서드가 생긴다면?
  • 보안상의 구멍이 생길 수 있다.
  • HashTable과 Vector를 컬렉션에 추가하자, 심각한 보안 구멍이 생긴적이 있다.
• 상위 클래스에 추가된 메서드가 만일 하위 클래스에 추가한 메서드와 시그니처가 같고 반환 타입만 다르다면?
  • 이 경우엔 컴파일 에러가 먼저 뜰 것이다.
  • 반환 타입 마저 같다고 하면 상위 클래스의 새 메서드를 재정의한 꼴이 된다.

상속의 단점을 개선한 방법: 컴포지션

static class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;
    public ForwardingSet(Set<E> set) {
        this.s = set;
    }

    @Override
    public Spliterator<E> spliterator() {
        return s.spliterator();
    }

    @Override
    public int size() {
        return s.size();
    }

    @Override
    public boolean isEmpty() {
        return s.isEmpty();
    }

    @Override
    public boolean contains(Object o) {
        return s.contains(o);
    }

    @Override
    public Iterator<E> iterator() {
        return s.iterator();
    }

    @Override
    public Object[] toArray() {
        return s.toArray();
    }

    @Override
    public <T> T[] toArray(T[] a) {
        return s.toArray(a);
    }

    @Override
    public boolean add(E e) {
        return s.add(e);
    }

    @Override
    public boolean remove(Object o) {
        return s.remove(o);
    }

    @Override
    public boolean containsAll(Collection<?> c) {
        return s.containsAll(c);
    }

    @Override
    public boolean addAll(Collection<? extends E> c) {
        return s.addAll(c);
    }

    @Override
    public boolean retainAll(Collection<?> c) {
        return s.retainAll(c);
    }

    @Override
    public boolean removeAll(Collection<?> c) {
        return s.removeAll(c);
    }

    @Override
    public void clear() {
        s.clear();
    }
}

static class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;

    public InstrumentedSet(Set<E> set) {
        super(set);
    }

    @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;
    }
}

• 얼핏보면 이전 HashSet을 상속하던 InstrumentedHashSet과 동일해보이지만, 명백히 다르다.
• InstrumentedSet은 ForwardingSet을 상속하여 만들었다.
  • ForwardingSet은 Set을 구현한 객체를 받아 사용할 뿐이기 때문에 HashSet을 상속했을 때처럼 기존 기능을 재정의한다기보다 앞뒤에 독립적인 새로운 부가기능을 넣는 방식이다.
• 기존 클래스의 내부 구현방식에 전혀 영향을 받지 않게 된다.
  • 기존 클래스에 새로운 메서드가 생겨도 아무런 영향이 없다.
• HashSet을 상속했을 때는 HashSet에만 카운트 기능을 넣을 수 있었지만, Set 인터페이스를 구현함으로써, TreeSet 등 Set 인터페이스만 구현하면 적용 가능해졌다.

@Test
public void instrumentSetTest() {
    InstrumentedSet<String> s = new InstrumentedSet<>(new TreeSet<>());
    s.addAll(List.of("A", "B", "C"));
    System.out.println("s.getAddCount() = " + s.getAddCount());
}

• 클라이언트 코드에 위와 같이 TreeSet을 적용시켜도 아무런 문제가 없다.
• 이를 데코레이터 패턴(Decorator Pattern)이라고 한다.
• 위와 같이 컴포지션과 전달 조합은 넓은 의미로 위임(delegation)이라고 한다.
  • 단, 엄밀히 따졌을 때는 래퍼 객체가 내부 객체에 자기 자신의 참조를 넘기는 경우만 위임에 해당한다.
• 래퍼 클래스는 단점이 거의 없다.
  • 다만, 콜백 프레임워크와 어울리지 않는 점만 주의하면 된다.
    • 콜백 프레임워크에서는 자신(this)의 참조를 넘기고 콜백 때는 래퍼가 아닌 내부 객체를 호출하게 된다.

// basic class which we will wrap
static class Model{
    private final Controller controller;

    Model(Controller controller){
        this.controller = controller;
        this.controller.register(this); //Pass SELF reference
    }

    public void makeChange(){
        System.out.println("Model.makeChange");
    }
}

static class Controller{
    private Model model;

    public void register(Model model){
        this.model = model;
    }

    // Here the wrapper just fails to count changes,
    // because it does not know about the wrapped object
    // references leaked
    public void doChanges(){
        System.out.println("Controller.doChanges");
        model.makeChange();
    }
}

// wrapper class
public class ModelChangesCounter{
    private final Model model;
    private int changesMade;

    ModelChangesCounter(Model model){
        this.model = model;
    }

    // The wrapper is intended to count changes,
    // but those changes which are invoked from
    // Controller are just skipped
    public void makeChange(){
        System.out.println("ModelChangesCounter.makeChange");
        model.makeChange();
        changesMade++;
        System.out.println(changesMade);
    }
}

@Test
public void callbackTest() {
    Controller c = new Controller();
    ModelChangesCounter m = new ModelChangesCounter(new Model(c));
    c.doChanges();
}

• 위는 콜백 프레임워크에서 발생되는 문제를 재현해본 것이다.
• 래퍼 클래스의 메서드인 makeChange()가 호출되는 것이 아니라, 단순 Model 클래스의 makeChange()가 호출된다.
  • 내부 객체는 자신을 감싸고 있는 래퍼의 존재를 모르고 자신의 참조를 넘겨버린다.

상속 주의점1: is-a 관계일 때만 상속하라

• 상속을 이용하려고 할 때는 클래스 B가 클래스 A에 대해 is-a 관계인지 자문해보자.
  • "그렇다"고 확신할 수 없다면, 상속 관계를 사용하지 않는 것이 좋다.
  • 자바 기본 API의 Stack은 Vector를 상속받아선 안 됐다.
    • 스택은 벡터가 아니다. (is-a 관계가 성립하지 않는다.)
  • Properties도 HashTable을 상속받아선 안 됐다.
    • 이로 인해 발생하는 더욱 심각한 문제는 Properties에서 get() 메서드와 getProperty() 메서드 둘 다 제공하는데, 둘의 결과가 다르다는 것이다.

상속 주의점2: 확장하려는 클래스 API에 결함은 없는가?

• 상속받게되면 상위 클래스 API의 결함까지도 그대로 상속받으므로 주의해야 한다.

핵심 정리

• 상속은 강력하지만 캡슐화를 해친다.
• 하위 클래스가 순수한 is-a 관계일 때만 써야 한다.
  • is-a 관계라고 안심할 수는 없다. 상속용으로 만들어진 클래스인지 다시 한번 확인해야 한다.
• 상속의 취약점을 피하려면 상속 대신 컴포지션과 전달을 사용하자.
• 래퍼클래스로 구현할 적당한 인터페이스가 있다면 적극 활용하자.