상속보다는 컴포지션을 사용하라 - [4장. 클래스와 인터페이스(아이템18)]

  상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다. 잘못 사용하면 오류를 내기 쉬운 소프트웨어를 만들게 된다. 상위 클래스와 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서라면 상속도 안전한 방법이다.

  확장할 목적으로 설계되었고 문서화도 잘 된 클래스도 마찬가질 안전하다. 하지만 일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일은 위험하다.

  여기서 다룰 '상속'은 클래스가 다른 클래스를 확장하는 '구현 상속'을 말한다. 클래스가 인터페이스를 구현하거나 인터페이스가 다른 인터페이스를 확장하는 '인터페이스 상속'과는 무관한 것이다.

  메서드 호출과 달리 상속은 캡슐화를 깨뜨린다. 문제가 발생하는 2가지 이유에 대해서 알아보고 해결책에 대해서 알아보자.

 

문제 1. 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 🛫

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

  성능을 높이려면 HashSet은 처음 생성된 이후 원소가 몇 개 더해졌는지 알 수 있어야 한다. 그러한 점을 고려하여 HashSet을 상속한 InstrumentedHashSet에서 addCount 변수를 추가하고, add와 addAll 메서드를 오버라이딩하였다. 그리고 아래와 같은 작업을 하였다고 생각해 보자.

 

public static void main(String[] args) {
    InstrumentedHashSet<String> s = new InstrumentedHashSet<>();
    s.addAll(List.of("틱", "탁탁", "펑"));
    System.out.println(s.getAddCount());
}

  3을 출력할 거라고 기대하겠지만, 실제로는 6을 출력한다. 그 이유는 HashSet의 addAll 메서드가 add메서드를 사용해 구현된 데 있다.

// 상위 클래스(AbstractCollection)에서의 addAll 메서드
public boolean addAll(Collection<? extends E> c) {
    boolean modified = false;
    for (E e : c)
        if (add(e))
            modified = true;
    return modified;
}

  우리가 만든 InstrumentedHashSet에서 HashSet의 addAll을 호출하기 전에 addCount에 3을 더함으로써 이미 업데이트해 주었다. 하지만 HashSet에서 addAll은 각 원소를 add 메서드를 호출해 추가하고 있다. 그 결과 오버라이딩한 add가 불리면서 다시 한번 addCount에 3을 더해준 것이다. 그래서 6이 나왔다.

  물론 하위 클래스에서 addAll 메서드를 재정의하지 않으면 문제를 고칠 수 있다. 하지만 당장은 제대로 동작할지 모르나, HashSet의 addAll이 add 메서드를 이용해 구현했음을 가정한 해법이라는 한계를 지닌다.

  그리고 allAll 메서드를 다른 식으로 재정의해서도 문제를 고칠 수 있다. 예를 들어 주어진 컬렉션을 순회하며 원소 하나당 add 메서드를 한 번만 호출하게 하는 것이다. 하지만 상위 클래스의 메서드 동작을 다시 구현하는 방식은 어렵고, 시간도 들고, 자칫 오류를 내거나 성능을 떨어뜨릴 수 있다는 문제가 있다. 또한 하위 클래스에서는 접근할 수 없는 private 필드를 써야 하는 상황이라면 이 방식으로는 구현 자체가 불가능하다는 문제가 있다.

 

문제 2. 상위 클래스에 새로운 메서드가 추가된다면 하위 클래스가 깨질 수 있다. 🛬

  상위 클래스의 구현 방식의 변화뿐만 아니라 상위 클래스에서 새로운 메서드가 생기는 경우에도 하위 클래스가 쉽게 깨질 수 있다.

  예를 들어 상위 클래스에서 보안을 이유로 컬렉션에 추가된 모든 원소가 특정 조건을 만족해야 하는 경우가 있다고 하자. 그러면 그 컬렉션을 상속하여 특정 원소를 추가하는 모든 메서드를 재정의해 필요한 조건을 먼저 검사하게끔 하면 된다.

  하지만 하위 클래스에서 위의 경우를 고려하지 않고 기존 방식대로 원소를 추가하게 된다면 '허용되지 않은' 원소를 추가하는 상황이 발생할 수 있다. 그리고 상위클래스에서 메서드가 추가되었다는 사실을 하위클래스에서 인지하기가 쉽지 않다,

 

해결책. 컴포지션(Composition)을 사용하라 💺

  앞서 살펴본 상속의 문제를 해결하기 위한 방법으로 컴포지션(Composition)이라는 것이 있다. 기존 클래스를 확장하는 대신, 새로운 클래스를 만들고 private 필드로 기존 클래스의 인스턴스를 참조하게 하는 것이다.

// 재사용할 수 있는 전달 클래스
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(); }
}

// 래퍼 클래스 - 상속 대신 컴포지션을 사용
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;
    }
}

  용어를 살펴보자.

• 컴포지션(Composition)
  기존 클래스가 새로운 클래스의 구성요소로 쓰인다는 뜻
• 전달(Forwarding)
  새 클래스의 인스턴스 메서드들은 기존 클래스의 대응하는 메서드를 호출해 그 결과를 반환하는 것
• 전달 메서드(Forwarding Method)
  새 클래스의 메서드들을 전달하는 것
• 래퍼 클래스(Wrapper Class)
  InstrumentedSet과 같이 다른 Set 인스턴스를 감싸고(wrap) 있는 것

  컴포지션을 사용하면 맨 처음 예시인 InstrumentedHashSet과 달리 상위 클래스에 영향을 받지 않게 된다.

public static void main(String[] args) {
    InstrumentedSet<String> s = new InstrumentedSet<>(new HashSet<>());
    s.addAll(List.of("틱", "탁탁", "펑"));
    System.out.println(s.getAddCount());
}

  즉, 사이드 이펙트가 없게 된다. InstrumentedHashSet과 달리 InstrumentedSet을 사용하면 6이 아닌 우리가 의도했던 대로 3이 나오게 된다.

  컴포지션을 사용하면 새로운 클래스는 기존 클래스의 내부 구현 방식의 영향에서 벗어나며(문제 1 해결), 심지어 기존 클래스에 새로운 메서드가 추가되더라도 전혀 영향을 받지 않는다(문제 2 해결). 그러므로 캡슐화가 완벽히 지켜지게 된다. (Set이 아닌 HashSet에만 메서드가 추가된다면 Forwarding 코드는 바뀌지 않는다. 만약 인터페이스에 새로운 메서드가 추가된다면 변화를 알아차릴 수밖에 없다.)

  또한, 컴포지션을 이용해서 한 번만 구현해 두면 어떠한 Set 구현체라도 계측할 수 있으며, 기존 생성자들과도 함께 사용할 수 있게 된다.

 

해당 글은 백기선 님의 '이펙티브 자바 완벽 공략'을 참고하였습니다.