항목 17. 상속을 위한 설계와 문서화를 하자. 그렇지 않면 상속의 사용을 금지시킨다.

항목 16에 이어서 상속꺼져. 라는 내용입니다.

아니뭐.. 진짜 꺼지라는건 아니고...


프로그래밍을 하다보면 여기저기서 라이브러리를 땡겨다 쓴다. java에 포함되어있는 api이외에도 기타 서드파티나 개인 개발자가 만든 라이브러리를 가져다 쓸떄가 있는데. 이것참.. 상속을 해서 쓰고는 싶은데 이게 어떻게 돌아가는 코드인지 알아야 상속을 하던 뭘하던 하지 않겠나?

add 메소드를 오버라이드 했는데 super.add 를 호출하지 않고 내가 원하는데로 코드를 짰다. 근데 알고보니 super.add에서 데이터를 체크한다던가 리스트의 크기를 늘린다던가 하는 기능이 있었고 그게 없으면 다른 메소드에서 이상한 짓을 해버릴지도 모른다.

가장 쉽게 배열을 이용해서 List를 구현했다고 할때 add를 하면서 사이즈를 늘려줘야하는데 내가 상속을해서 집어넣는 과정에 사이즈를 늘려주는 과정을 생략했다면? 우왕ㅋ굳ㅋ 

이처럼 간단하게도 상속의 폐혜를 알수있다. 위의 예는 너무나도 당연한것이 아닌가? 라고 반문할수도 있겠지만 저런 단순한것들을 제외하고 복잡하게 구성된 라이브러리라면 상속같은걸 할 엄두가 안날것이다.

그렇다면 여태까지 말한 내용을 종합해보면 클레스나 메소드가 어떻게 동작하는지 상세히 기록하라는 의미로 들린다.
그런데 좋은 API문서는 메소드가 어떤 일을 하는지를 기술하고, 어떻게 일을 하는지에 대해서는 숨겨야 한다고 말한다. 그렇다면 위의 내용은 그것을 무시하는내용이 아닌가? 

게다가 어떻게 돌아가는지 문서화 하는것도 짜증난다귀찮다. JavaDoc가 만들기 쉽긴하지만 그것조차 귀찮은떄가 한두번인가.. 파라미터는 뭐고 리턴은 뭐고 예외는 이거다. 라고 적는것도 귀찮아서 안하는 판국에..

 
근데 별수없다. 오버라이드 못하게 final 메소드로 만들어버리던지 final 클레스로 만들던지 아니면 위와같은 일이 안생기도록 엄청나게 클레스 디자인을 잘하던지... 아니면 API문서에 상속에 관한 내용을 문서화 하던지.

결론. 나도몰라 ㅅㅂ