[이펙티브 자바] Item19. 상속을 고려해 설계하고 문서화하라. 그렇지 않았더라면 상속을 금지하라.

 

[이펙티브 자바] Item19. 상속을 고려해 설계하고 문서화하라. 그렇지 않았더라면 상속을 금지하라. 

[이펙티브 자바] Item18. 상속보다는 컴포지션을 사용하라. (tistory.com)

[이펙티브 자바] Item18. 상속보다는 컴포지션을 사용하라.

item18에서는 상속을 염두에 두지 않고 설계하고 상속할 때 주의점도 문서화해놓지 않은 외부 클래스를 상속할 때의 문제점에 대해서 얘기하고 있다. (이때 '외부'란 프로그래머의 통제권 밖에 있어서 언제 어떻게 변경될지 모르는 상황을 말한다.) 

 

 

 

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

: 메서드를 재정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야 한다. 

 

클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다. 그런데 마침 호출되는 메서드가 재정의 가능 메서드라면 그 사실을 호출하는 메서드의 API 설명에 적시해야 한다. 그리고 추가로 어떤 순서로 호출되는지, 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지도 담아야 한다. 

더 넓게 말하면 재정의 가능 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야 한다!!

 

API 문서의 메서드 설명 끝에 종종 "Implemetation Requirements"로 시작하는 절을 볼 수 있는데, 그 부분이 그 메서드의 내부 동작 방식을 설명하는 곳이다. 이 절은 메서드 주석에 @implSpec 태그를 붙여주면 자바독 도구가 생성해준다. 

 

AbstractCollection

Implementation Requirements로 시작하는 절에서 메서드의 내부 동작 방식에 대해서 설명하고 있는데 여기서는 iterator 메서드를 재정의하면 remove 메서드의 동작에 영향을 줌을 확실히 알 수 있다. 

 

 

❗ 그런데 좋은 API 문서란 '어떻게'가 아닌 '무엇'을 하는지를 설명해야 한다 라는 격언과는 맞지않다. 하지만 상속이 캡슐화를 해치기 때문에 일어나기 때 어쩔 수 없다.. 클래스를 안전하게 상속할 수 있도록 하려면 내부 구현 방식을 설명해야만 한다. 

 

 

/**
 * item19. 상속을 고려해 설계하고 문서화하라. 그렇지 않았더라면 상속을 금지하라.
 * Example class for java documentation for extendable class
 */
public class ExtendableClass
{
   /**
    * This method can be overridden to print any message
    *
    * @implSpec
    * Please use System.out.println()
    */
   public void doSomething()
   {
      System.out.println("hello");
   }
}

@implSpec 태그는 자바 8에서 처음 도입되어서 자바9부터 본격적으로 사용되기 시작했는데 자바 11의 자바독에서는 선택사항으로 남겨졌다. 

따라서 이 태그를 활성화하기 위해서는 -tag "implSpec:a:Implementation Requirements:"를 지정해주면 된다. 

자바독을 생성하고 나면 method detail에서 @implSpec 태그를 사용해서 작성한 메서드 내부 동작 방식에 대한 설명을 확인할 수 있다. 

 

 

 

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

상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출해야 할지는 어떻게 결정할까 에 대해서는 답이 없다. 

심사숙괘서 잘 예측한 다음에 실제 하위 클래스를 만들어 시험해보는 것이 최선이다..!! 

 

 

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

 

 

4️⃣ 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.  

 

 

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

: 이 규칙을 어긴다면 오동작할 것이다!! 

 

public class Super
{
   /**
    * 재정의 가능 메서드를 호출하는 생성자 -> 따라하면 x
    */
   public Super()
   {
      overrideMe(); // 생성자가 재정의 가능한 메서드를 호출하고 있다.
   }
   
   public void overrideMe()
   {
   
   }
}

public final 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();
   }
}

Sub은 Super 클래스의 하위 클래스로 override 메서드를 재정의했다. 

main에서 sub의 동작 방식을 예측해보면 instant 시간 2번 출력될 것이라고 생각한다. 

하지만 출력 결과를 확인해보면 

이렇게 동작하는 이유는 상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되므로 하위 클래스에서 재정의한 메서드가 하위 클래스의 생성자보다 먼저 호출한다. 

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

 

여기서도 상위 클래스의 생성자는 하위 클래스의 생성자가 인스턴스 필드를 초기화하기도 전에 overrideMe 를 호출하기 때문에 첫번째 값은 null이 출력된다. 

 

 

6️⃣ 클래스를 상속용으로 설계하려면 엄청난 노력이 들고 그 클래스에 안기는 제약도 상당하다. 이 문제를 해결하는 가장 좋은 방법은 상속용으로 설계하지 않은 클래스는 상속을 금지하는 것이다. 

: 상속을 금지하는 방법은 두가지로 첫번째는 클래스를 final로 선언하는 방법이고, 두번째는 모든 생성자를 private나 package-private로 선언하고 public 정적 팩터리 메서드를 만들어주는 방법이다. 

 

 

 

 

📚 정리

상속용 클래스를 설계한다는 것은 클래스 내부에서 스스로를 어떻게 사용하는지 모두 문서로 남겨야 하고, 일단 문서화한 것은 그 클래스가 쓰이는 한 반드시 지켜져야 한다. (그렇지 않으면.. 그 내부 구현 방식을 믿고 활용하던 하위 클래스에서 오동작을 만들수 있다.) 

따라서 클래스를 확장해야 하는 명확한 이유가 떠오르지 않는다면 상속을 금지하는 것이 더 나을 것이다. 

상속을 금지하는 방법으로는 클래스를 final로 선언하거나 생성자 모두를 외부에서 접근할 수 없도록 만들면 된다.