Item19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

• 상속용 클래스는 내부 구현을 문서로 남겨야 한다.
  • @implSpac을 사용할 수 있다.
• 내부 동작 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드로 공개해야 한다.
• 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야한다.
• 상속용 클래스의 생성자는 재정의 가능한 메서드를 호출해서는 안된다.
  • Cloneable과 Serializable을 구현할 때 조심해야 한다.
• 상속용으로 설계한 클래스가 아니라면 상속을 금지한다.
  • final 클래스 또는 private 생성자

상속을 고려한 설계와 문서화는 메서드를 재정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야한다.

상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 사용하는지 문서로 남겨야 한다. (재정의 가능이란 public과 protected 메서드 중 final이 아닌 모든 메서드를 뜻함)

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

 

 

 

효율적인 하위 클래스를 큰 어려움 없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected메서드 형태로 공개해야할 수도 있다. 드물게는 protected 필드로 공개할 수도 있다.

그렇다면 상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출해야 할지는 어떻게 결정할까? 실제 하위 클래스를 만들어 시험해보는 것이 최선이다. 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 유일하다. 하위 클래스 3개 정도 만들어보고 이 중 하나 이상은 제 3자가 작성해봐야 한다.

 

널리 쓰일 클래스를 상속용으로 설계한다면 문서화한 내부 패턴과, protected 메서드와 필드를 구현하면서 선택한 결정에 영원히 책임져야 함을 잘 인식해야 한다. 그러니 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다. 

 

상속을 허용하는 클래스가 지켜야 하는 다른 제약은 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안된다.

 

• 상속용 클래스는 내부 구현을 문서로 남겨야 한다.
  • @implSpac을 사용할 수 있다.
• 내부 동작 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드로 공개해야 한다.
• 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야한다.
• 상속용 클래스의 생성자는 재정의 가능한 메서드를 호출해서는 안된다.
  • Cloneable과 Serializable을 구현할 때 조심해야 한다.
• 상속용으로 설계한 클래스가 아니라면 상속을 금지한다.
  • final 클래스 또는 private 생성자

상속을 고려한 설계와 문서화는 메서드를 재정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야한다.

상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 사용하는지 문서로 남겨야 한다. (재정의 가능이란 public과 protected 메서드 중 final이 아닌 모든 메서드를 뜻함)

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

 

 

 

효율적인 하위 클래스를 큰 어려움 없이 만들 수 있게 하려면 클래스의 내부 동작 과정 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected메서드 형태로 공개해야할 수도 있다. 드물게는 protected 필드로 공개할 수도 있다.

그렇다면 상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출해야 할지는 어떻게 결정할까? 실제 하위 클래스를 만들어 시험해보는 것이 최선이다. 상속용 클래스를 시험하는 방법은 직접 하위 클래스를 만들어보는 것이 유일하다. 하위 클래스 3개 정도 만들어보고 이 중 하나 이상은 제 3자가 작성해봐야 한다.

 

널리 쓰일 클래스를 상속용으로 설계한다면 문서화한 내부 패턴과, protected 메서드와 필드를 구현하면서 선택한 결정에 영원히 책임져야 함을 잘 인식해야 한다. 그러니 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다. 

 

상속을 허용하는 클래스가 지켜야 하는 다른 제약은 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안된다.

 

Sub 클래스를 인스턴스화 할 때 생성자를 호출하며 Super의 생성자가 먼저 호출되고 내부의 overrideMe메서드는 실제 사용 객체인 Sub의 override 메서드가 실행된다. instant 필드가 초기화 되지 않은 상태로 null이 찍히고 그 후 Sub 클래스의 생성자 구현 로직이 실행되며 instant에 초기값이 세팅되고 해당 현재 날짜가 찍히게 된다.

Cloneable과 Serializable 인터페이스는 객체를 생성하는 역할을 가진 인터페이스로 위와 같이 clone과 readObject를 재정의를 가능하게 한다면 초기값이 제대로 세팅되기 전에 객체를 만들어 오작동을 일으킬 수 있다.

 

상속용으로 설계하지 않은 클래스는 상속을 금지해라

클래스를 final로 선언하거나 생성자를 private나 package-private로 선언하고 public 정적 팩터리를 만들어 줘라.

 

https://www.inflearn.com/course/%EC%9D%B4%ED%8E%99%ED%8B%B0%EB%B8%8C-%EC%9E%90%EB%B0%94-2/dashboard