아이템 19 - 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라.
JAVA ·상속을 고려해 설계하고 문서화하라.
- 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다.
- 클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수 있다.
호출되는 메서드가 재정의 가능 메서드라면 그 사실을 호출하는 메서드의 API 설명에 적시해야 한다, - 메서드 주석에 @ImplSpec 태그를 붙여주면 자바독 도구가 생성해준다.
- 클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수 있다.
- 내부 동작 중간에 끼어들 수 있는 훅(hook)을 잘 선별하여 protected 메서드로 공개해야 한다.
- 심사숙고해서 잘 예측해본 다음, 실제 하위 클래스를 만들어 시험하여 protected 메서드를 선별해라.
- protected 메서드는 하나하나가 내부 구현에 해당하므로 그 수는 가능한 한 적어야 한다.
- 한편으로는 너무 적게 노출해서 상속으로 얻는 이점마저 없애지 않도록 주의해야 한다.
- 상속용으로 설계한 클래스는 배포 전에 반드시 하위 클래스를 만들어 검증해야 한다.
- 문서화한 내부 사용 패턴과 protected 메서드와 필드를 구현하면서 선택한 결정에 영원히 책임져야 하고,
이 결정들이 그 클래스의 성능과 기능에 영원한 족쇄가 될 수 있다.
- 문서화한 내부 사용 패턴과 protected 메서드와 필드를 구현하면서 선택한 결정에 영원히 책임져야 하고,
- 상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능한 메서드를 호출해서는 안된다.
- 상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되므로 하위 클래스에서 재정의한 메서드가 하위 클래스의 생성자보다 먼저 호출된다. 이때 그 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면 의도대로 동작하지 않을 것이다.
- private, fianl, static 메서드는 재정의가 불가능하니 생성자에서 안심하고 호출해도 된다.
- Cloneable과 Serializable을 구현할 때 조심해야 한다.
- clone과 readObject 메서드는 생성자와 비슷한 효과를 낸다.
- 상속용으로 설계한 클래스가 아니라면 상속을 금지한다.
- final 클래스 또는 private 생성자