이펙티브 자바 Item 19 - 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

 

상속을 고려한 설계와 문서화란?

 

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

클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다. 

그 메서드가 재정의 가능 메서드(protected, public, final이 아닌 메서드)라면 그 사실을 호출하는 메서드의 API설명에 적시해야한다. 

출처 : https://sasca37.tistory.com/259

• API 문서의 메서드 설명 끝에 implementation Requirements로 시작하는 절이 있는데, 이 절이 메서드 내부 동작 방식을 설명하는 곳이다. @implSpec태그를 붙여서 작성하여, 자바독 도구가 생성해준다.
• 해당 설명에 따라 iterator메서드를 재정의하면 remove 메서드에 영향을 준다는 점을 알 수 있다. 

 

protected 공개 

 

내부 메커니즘을 문서로 남기는 것만이 상속을 위한 설계의 전부는 아니다. 효율적인 하위 클래스를 어려움 없이 만들 수 있게 하려면, 클래스 내부 동작 중간 과정에 끼어들 수 있는 훅을 잘 선별하여 protected메서드 형태로 공개할 수도 있다.

출처 : https://sasca37.tistory.com/259

• java.util.Abstract의 removeRange메서드이다. List 구현체의 최종 사용자는 해당 메서드에 관심이 없다.
• 그럼에도 이 메서드를 제공한 이유는 단지 하위 클래스에서 부분 리스트의 clear 메서드를 고성능으로 만들기 쉽게 하기 위해서다.