상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라 - [4장. 클래스와 인터페이스(아이템19)]

  상속을 고려해 설계하고 문서화하는 방법들을 알아보자.

 

1. 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지(자기 사용) 문서로 남겨야 한다. 🛺

  재정의 가능 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야 한다.

  유명한 격언 중 하나인 "좋은 API 문서란 '어떻게'가 아닌 '무엇'을 하는지를 설명해야 한다"와 대치되는 내용이기도 하다.    하지만 상속이 캡슐화를 해치기 때문에 클래스를 안전하게 상속할 수 있도록 하려면 '상속만 아니었다면 기술하지 않았어야 할' 내부 구현 방식을 설명해야 한다.

  AbstractCollection.java의 remove 메서드를 살펴보자.

  위와 같이 API 문서의 메서드 설명 끝에 "Implementation Requirements"가 붙은 걸 볼 수 있는데 이것이 내부 동작 방식을 설명하는 곳이다. IntelliJ의 오른쪽 위에 있는 Reader Mode를 선택하면 위와 같은 형태로 나온다. 아래는 Reader Mode를 취소한 경우이다.

// AbstractCollection.java

/**
 * {@inheritDoc}
 *
 * @implSpec
 * This implementation iterates over the collection looking for the
 * specified element.  If it finds the element, it removes the element
 * from the collection using the iterator's remove method.
 *
 * <p>Note that this implementation throws an
 * {@code UnsupportedOperationException} if the iterator returned by this
 * collection's iterator method does not implement the {@code remove}
 * method and this collection contains the specified object.
 *
 * @throws UnsupportedOperationException {@inheritDoc}
 * @throws ClassCastException            {@inheritDoc}
 * @throws NullPointerException          {@inheritDoc}
 */
public boolean remove(Object o) {
    Iterator<E> it = iterator();
    if (o==null) {
        while (it.hasNext()) {
            if (it.next()==null) {
                it.remove();
                return true;
            }
        }
    } else {
        while (it.hasNext()) {
            if (o.equals(it.next())) {
                it.remove();
                return true;
            }
        }
    }
    return false;
}

  해당 절은 메서드 주석에 @implSpec 태그를 붙여주면 자바독 도구가 생성해 준다. 이 태그는 기본값으로 설정되어 있지 않기 때문에 다음과 같은 옵션을 추가해주어야 한다.

-tag "implSpec:a:Implementation Requirements:"

 

2. 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드 형태로 공개해야 할 수도 있다. 🚙

  java.util.AbstractList의 removeRange 메서드를 살펴보자.

public abstract class AbstractList<E> extends AbstractCollection<E> implements List<E> {

    ...
    
    public void clear() {
        removeRange(0, size());
    }
    
    protected void removeRange(int fromIndex, int toIndex) {
        ListIterator<E> it = listIterator(fromIndex);
        for (int i=0, n=toIndex-fromIndex; i<n; i++) {
            it.next();
            it.remove();
        }
    }
}

  이 메서드는 protected로 제공하고 있다. 그 이유는 clear 메서드에서 이를 사용하여 clear메서드를 고성능으로 만들기 쉽게 하기 위해서다. 당연한 말이지만 private로 설정하면 상속받은 곳에서 해당 메서드를 사용할 수 없고, 클래스의 내부 동작 과정에서만 사용할 것이므로 public으로 설정할 필요도 없다.

 

3. 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 '유일'하다. 🚜

  2번에서 살펴본 것과 같이 상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출해야 할까? 정해진 정답은 없다. 아쉽지만 잘 예측해 보고, 실제 하위 클래스를 만들어 시험해 보는 것이 최선이다.

  책에서는 하위 클래스를 3개 정도 만들어 보는 것을 추천하고 있다. 그리고 이 중 하나 이상은 제 3자가 작성하는 것을 추천한다.

 

4. 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다. 🚎

  상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되므로 하위 클래스에서 재정의한 메서드가 하위 클래스의 생성자보다 먼저 호출된다.

  이때 그 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면 의도대로 동작하지 않을 것이다.

public class Super {
    
    // 잘못된 예 - 생성자가 재정의 가능 메서드를 호출한다.
    public Super() {
        overrideMe();
    }

    public void overrideMe() {
    }
}

----------

public class Sub extends Super {

    // 초기화되지 않은 final 필드. 생성자에서 초기화된다.
    private final Instant instant;

    Sub() {
        instant = Instant.now();
    }

    // 재정의 가능 메서드. 상위 클래스의 생성자가 호출한다.
    @Override
    public void overrideMe() {
        System.out.println(instant);
    }
}

----------

public static void main(String[] args){
    Sub sub = new Sub();
    sub.overrideMe();
}

  코드에서 알 수 있듯이 상위 클래스의 생성자가 재정의한 메서드인 overrideMe()를 호출하여 NullPointerException이 발생한다. (하지만 NullPointerException이 발생하지 않는데 그 이유는 prinln이 null 입력도 받아들이기 때문이다.)

  또한, Cloneable과 Serializable 인터페이스는 상속용 설계의 어려움을 한층 더해준다. clone과 readObject 메서드는 새로운 객체를 만든다는 점에서 생성자와 비슷한 효과를 내기 때문이다. 그러므로 clone과 readObject 모두 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다.

 

5. 상속을 고려해 설계하고 문서화하지 않았다면, 상속을 금지하라 🚊

  지금까지 상속용으로 클래스를 설계하고 문서화하는 방법을 알아보았다. 하지만 이러한 방법들을 지키지 않아서 상속용으로 설계하지 않은 클래스가 있다면 어떻게 해야 할까? 당연한 얘기지만, 상속을 금지해야 한다.

  또한, 클래스를 확장해야 할 명확한 이유가 떠오르지 않으면 상속을 금지하는 편이 낫다.

  상속을 금지하는 2가지 방법이 있는데, 첫 번째로는 클래스를 final로 선언하는 방법이고, 두 번째로는 모든 생성자를 private이나 package-private으로 선언하고 public 정적 팩터리를 만들어주는 방법이다. (두 가지 방법은 '변경 가능성을 최소화하라 - 아이템17'의 첫 번째 내용과 두 번째 내용을 참고하자.)

 

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