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

[chikeem90]

상속용 클래스 설계 시 지켜야할 사항

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

재정의 가능한 메서드란 public과 protected 메서드 중 final이 아닌 모든 메서드를 의미

• 클래스의 API로 공개된 메서드에서 클래스 자신의 또 다른 메서드를 호출할 수 있는데, 그 호출되는 메서드가 재정의 가능 메서드인 경우 그 사실을 호출하는 메서드의 API 설명에 적시해야 함.
• 어떤 순서로 호출하는지, 각각의 호출 결과가 이어지는 처리에 어떤 영향을 주는지도 담아야 함.
• 즉, 재정의 가능 메서드를 호출할 수 있는 모든 상황을 문서로 남겨야 함.
• API 문서 메서드 설명 끝에서 "Implementation Requirements"로 메서드의 내부 동작 방식을 설명하면 되는데, 이는 메서드 주석에 @implSpec태그를 붙이면 자바독 도구가 생성해줌.
• ex) java.util.AbstractCollection

@implSpec은 자바독의 커스텀 태그 기능을 이용해 자바 개발팀에서 내부적으로 사용하는 규약.

javadoc 실행 시 -tag "implSpec:a:Implemetation Requirements:"를 지정

public class Main {
    public void overrideMe() {
        System.out.println("Do A");
    }

    public final void callOverrideMe() {
        overrideMe();
    }
}

public class Sub extends Main {
    @Override
    public void overrideMe() {
        System.out.println("Do B");
    }

    public static void main(String[] args) {
        Sub sub = new Sub();
        sub.callOverrideMe();
    }
}

• Main 클래스의 overriveMe 메서드만 오버라이드했을 뿐인데 callOverrideMe 메서드의 동작 방식이 바뀌는 것을 확인 할 수 있음.
• 그렇기 때문에 재정의 가능한 메서드를 내부적으로 호출하는 형태인 경우 반드시 문서화하여 어떻게 구현해야할 지 명시해두어야 함.

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

• 또는 드물게 protected 필드로 공개해야 할 수도 있음.

• ex) java.util.AbstractList의 removeRange

  • 주의: ListIterator.remove가 선형 시간이 걸리면 이 구현의 성능은 제곱에 비례한다.
  • AbstractList의 removeRange 메서드는 접근 제한자가 protected로, 실제 구현체를 사용할 때는 removeRange 메서드를 직접 호출할 수 없고 clear 메서드를 통해 호출되는 형태.
  • 그렇기 때문에 최종 사용자는 removeRange 메서드에 굳이 알아야 할 필요가 없지만, 그럼에도 불구하고 따로 메서드로 빼서 제공하는 이유는 하위 클래스에서 clear 메서드를 고성능으로 만들기 쉽게 하기 위해서임.

• AbstractList의 removeRange 메서드

    protected void removeRange(int fromIndex, int toIndex) {
        ListIterator<E> it = listIterator(fromIndex);
        for (int i=0, n=toIndex-fromIndex; i<n; i++) {
            it.next();
            it.remove();
        }
    }

• 구현체인 ArrayList의 removeRange 메서드

    protected void removeRange(int fromIndex, int toIndex) {
        if (fromIndex > toIndex) {
            throw new IndexOutOfBoundsException(
                    outOfBoundsMsg(fromIndex, toIndex));
        }
        modCount++;
        shiftTailOverGap(elementData, fromIndex, toIndex);
    }

• 이렇게 구현체에서 성능상 더 나은 방식으로 removeRange 메서드를 구현하고 있음.

3. 상속용 클래스의 하위 클래스를 직접 만들어서 테스트하라

• 상속용 클래스를 설계할 때 어떤 메서드를 protected로 노출해야할지 결정하는 방법은 잘 예측해본 다음 실제 하위 클래스를 만들어 시험해 보는 것이 최선.
• 꼭 필요한 protected 멤버를 놓쳤다면 하위 클래스를 작성할 때 그 빈자리가 확연히 드러남.
• 하위 클래스를 여러 개 만들 때까지 전혀 쓰이지 않는 protected 멤버는 private이었어야 할 가능성이 큼.
• 이러한 검증에는 하위 클래스 3개 정도 테스트해보는 것이 적당하다

4. 상속용 클래스의 생성자는 재정의 가능 메서드를 호출해서는 안 된다

• 상위 클래스의 생성자가 하위 클래스의 생성자보다 먼저 실행되기 때문에 하위 클래스에서 재정의한 메서드가 하위 클래스의 생성자보다 먼저 호출됨.
• 이때 재정의한 메서드가 하위 클래스의 생성자에서 초기화하는 값에 의존한다면 의도대로 동작하지 않음.

public class Main {
    public Main() {
        System.out.println("Main constructor");
        overrideMe();
    }

    public void overrideMe() {
        System.out.println("Main overrideMe : " + this);
    }
}

public class Sub extends Main {
    private final Instant instant;

    public Sub() {
        System.out.println("Sub constructor");
        this.instant = Instant.now();
    }

    @Override
    public void overrideMe() {
        System.out.println("Sub overrideMe : " + this);
        System.out.println(instant);
    }

    public static void main(String[] args) {
        Sub sub = new Sub();
        sub.overrideMe();
    }
}

• 상위 클래스의 생성자가 먼저 호출되기 때문에 문제가 됨.
• 상위 클래스의 생성자는 하위 클래스의 생성자가 인스턴스 필드를 초기화하기도 전에 overrideMe를 호출하기 때문.

5. Cloneable 또는 Serializeable 인터페이스를 구현한 클래스를 상속할 수 있게 설계한 경우에는 반드시 clone 또는 readObject 모두 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다

• readObject의 경우 하위 클래스의 상태가 미처 다 역직렬화되기 전에 재정의한 메서드부터 호출하게 됨.
• clone의 경우 하위 클래스의 clone 메서드가 복제본의 상태를 수정하기 전에 재정의한 메서드를 호출함.

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

• 상속을 금지하기 위해서는 클래스를 final로 선언하거나, 모든 생성자를 private 또는 package-private으로 선언하고 public 정적 팩터리를 만들자.
• 상속을 꼭 허용해야하는 경우 클래스 내부에서 재정의 가능 메서드를 사용하지 않도록 만들고 문서로 남기는 경우, 메서드를 재정의해도 다른 메서드의 동작에 아무런 영향을 주지 않기 때문에 위험하지 않은 클래스를 만들 수 있음.

(참고) 클래스의 동작을 유지하면서 재정의 가능 메서드를 사용하는 코드를 제거할 수 있는 방법

1. 각각의 재정의 가능 메서드는 자신의 본문 코드를 private 도우미 메서드로 옮기고, 이 도우미 메서드를 호출하도록 수정.
2. 재정의 가능 메서드를 호출하는 다른 코드들을 모두 이 도우미 메서드를 직접 호출하도록 수정.

[JoisFe]

오우 아직 읽진 않았지만 늦은시간 고생 많으십니다. 읽고 질문 남길게요

[chikeem90]

늦어서,, 죄송,, 🙏

[JoisFe]

아닙니다 ㅎㅎ

[Irisation23]

정리 해 주신글 잘 읽었습니다. 굉장히 심오한 주제를 맡으셨군요 👍

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

왜 굳이 문서로 남겨야 할까라는 의문이 들었는데 OOP 원칙 중 LSP가 생각이 났습니다.

LSP (Liskov Substitution Principle) 리스코프 치환 원칙)

프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다는 원칙

즉 부모 클래스를 상속한 자식 클래스가 메서드를 재정의할 때 상위 타입에서 의도한 기능을 벗어나버린 상황을 의미하는 즉 정확성을 깨뜨리게 재정의할 수 있는 상황을 막고자 문서로 남기는 것이 아닐까? 라는 생각을 하게 되었습니다.

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

참 해당 지문은 비문학 수능 시험보는 느낌이네요 😢

[JoisFe]

오 맞는 것 같습니다. OOP를 지킨다는게 쉽지 않지만 문서를 남기고 해당 문서를 참고하여 메서드를 재정의 한다면 LSP를 잘 지킬 수 있을 것 같습니다.

[chikeem90]

참 해당 지문은 비문학 수능 시험보는 느낌이네요 😢

ㅎㅎ,, 저도 해당 문구만 봤을 땐 잘 이해가 안됐는데,, 예시를 보면 말 그대로 상속용 클래스의 메서드 중 몇 개를 적절히 protected로 열어줘서 상위 클래스의 구현된 기능보다 좀 더 효율적으로 구현해서 쓸 수 있도록 제공해라 정도 인 거 같네요

[YuDeokRin]

글 잘 읽었습니다.

chikeem90 님 작성하시는데 고생 많으셨습니다.

다들 새벽에도 열심히 하시네요 !

[corock]

개인적으로 이 장에서 제일 인상 깊었던 한 부분을 고르자면 다음 문장을 고를 것 같습니다.

p. 123 일부 발췌 (...)
하지만 이런 식은 "좋은 API 문서란 '어떻게'가 아닌 '무엇'을 하는지를 설명해야 한다"라는 격언과는 대치되지 않나?
그렇다. 상속이 캡슐화를 해치기 때문에 일어나는 안타까운 현실이다.

객체지향 프로그래밍을 처음 배울 때 어디에서나 4대 특징을 대표하여 추상화, 캡슐화, 상속, 다형성을 중요하게 다룹니다.
하지만 그중 한 특징이 다른 특징에 해를 끼칠 수 있다는 아이러니함이 또 다른 관점으로 바라보고 시야를 넓힐 수 있는 계기가 되었네요.