728x90
728x90
아이템 18에서는 상속을 염두에 두지 않고 설계했고 상속할 때의 위험을 경고했다. 그렇다면 상속을 고려한 설계와 문서화란 정확히 무얼 뜻할까? 우선, 메서드를 재정의하면 어떤 일이 일어나는지를 정확히 정리하여 문서로 남겨야 한다. 즉, 상속용 클래스는 재정의할 수 있는 메서드들을 내부적으로 어떻게 이용하는지 문서로 남겨야 한다. 클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수도 있다. 그런데 마침 호출되는 메서드가 재정의 가능한 메서드라면 그 사실을 호출하는 메서드의 API 설명에 적시해야 한다. 덧붙여서 어떤 순서로 호출하는지, 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지도 담아야 한다('재정의 가능'이란 public과 protected 메서드 중..
상속은 코드를 재사용하는 강력한 수단이지만, 항상 최선은 아니다. 잘못 사용하면 오류를 내기 쉬운 소프트웨어를 만들게 된다. 상위 클래스와 하위 클래스를 모두 같은 프로그래머가 통제하는 패키지 안에서라면 상속도 안전한 방법이다. 확장할 목적으로 설계되었고 문서화도 잘 된 클래스도 마찬가지로 안전하다. 하지만 일반적인 구체 클래스를 패키지 경계를 넘어, 즉 다른 패키지의 구체 클래스를 상속하는 일은 위험하다. 이전과는 달리 이번 아이템에서 논하는 문제는 (클래스가 인터페이스를 구현하거나 인터페이스가 다른 인터페이스를 확장하는) 인터페이스 상속과는 무관하다. 메서드 호출과는 달리 상속은 캡슐화를 깨뜨린다. 다르게 말하면, 상위 클래스가 어떻게 구현되느냐에 따라 하위 클래스의 동작에 이상이 생길 수 있다. 상..
상속이라는 개념을 이론적으로 분명 학습했는데, 잘 안쓰다보니(직접 만들어 쓴적은 없다는 얘기... JpaRepository 인터페이스 같은 것은 자주 사용...) 그 개념을 자꾸 잊어먹어서 implements, extends 심지어 추상 클래스 ,메서드인(명칭만 기억하지 기능은 기억도 안나는 것 같다.. 반성한다) abstract 등 한번 기회 잡아서 다시 정리해야지하며 미뤘는데, 어쩌다보니 스터디원분이 상속 얘기를 꺼내면서, 매우 진땀을 흘렸다. 민망해서 밤에 이불킥 몇 번 하다가 내 선생님인 '구글'을 찾아봤다. 마침 간단하게 잘 요약해둔 블로그가있어서, 옮겨적어본다. 참고: https://velog.io/@hkoo9329/%EC%9E%90%EB%B0%94-extends-implements-%EC%B..