컴포지션과 상속 (Composition vs Inheritance)

컴포지션(Composition)은 다른 객체를 필드로 소유하고 그 기능을 위임(delegation)해서 재사용하는 설계 기법이고, 상속(Inheritance)은 부모 클래스를 확장해 구현을 물려받는 기법이다. 두 방식 모두 코드 재사용을 목적으로 하지만, 상속은 부모의 내부 구현에 강하게 결합되는 반면 컴포지션은 공개된 인터페이스에만 의존하므로 변경에 훨씬 유연하다. 그래서 객체지향 설계에서는 순수한 is-a 관계가 아니라면 상속보다 컴포지션을 우선하라는 원칙이 널리 통용된다.

상속의 문제: 캡슐화가 깨진다

상속은 extends 한 줄로 부모의 모든 공개 기능을 물려받는 강력한 도구지만, 자식이 부모의 내부 구현 방식에 의존하게 만든다는 근본적인 약점이 있다. 부모 클래스가 다음 버전에서 내부 구현을 바꾸면, 부모 코드는 한 줄도 건드리지 않았는데 자식 클래스가 오동작할 수 있다. 이를 취약한 기반 클래스 문제(fragile base class problem)라 한다.

대표적인 사례가 자기 사용(self-use) 문제다. 아래처럼 HashSet을 상속해 추가된 원소 수를 세는 클래스를 만들면, addAll이 내부적으로 add를 호출하는 구현 세부 사항 때문에 카운트가 두 배로 늘어난다.

class CountingSet<E> extends HashSet<E> {
    private int addCount = 0;

    @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); // 내부에서 add를 다시 호출한다
    }
}

CountingSet<String> set = new CountingSet<>();
set.addAll(List.of("a", "b", "c"));
// addCount는 3이 아니라 6이 된다

이 버그는 HashSet의 문서에 없는 내부 동작에 의존했기 때문에 생겼고, 부모의 구현이 바뀌면 고쳐 놓은 코드가 다시 깨질 수도 있다.

컴포지션으로 바꾸면

같은 요구사항을 컴포지션으로 풀면, 기존 Set을 필드로 소유하고 모든 호출을 그대로 전달하는 전달 클래스(forwarding class)를 만든 뒤 필요한 메서드만 확장한다. 이렇게 기존 객체를 감싸는 구조를 래퍼(wrapper)라 하고, 기능을 덧붙인다는 의미에서 데코레이터 패턴(Decorator Pattern)이라고도 부른다.

class CountingSet<E> implements Set<E> {
    private final Set<E> inner; // 구현이 아니라 인터페이스에 의존한다
    private int addCount = 0;

    CountingSet(Set<E> inner) { this.inner = inner; }

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

    @Override
    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return inner.addAll(c); // inner가 내부적으로 무엇을 하든 무관하다
    }

    public int getAddCount() { return addCount; }

    // 나머지 Set 메서드는 inner에 위임한다
}

inner의 addAll이 내부에서 무엇을 호출하든 바깥 클래스의 카운트에는 영향이 없다. 게다가 생성자에 HashSet이든 TreeSet이든 어떤 Set 구현체라도 넣을 수 있어, 하나의 래퍼로 모든 구현체에 기능을 덧붙일 수 있다. 상속이었다면 구현체마다 자식 클래스를 따로 만들어야 했을 것이다.