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

아이템 18에서 상속을 염두해 두지 않은 메소드 설계의 위험성을 보았다.

public과 protected 메소드 중 final로 설정하지 않아 재정의가 가능한 메소드들은

상속시에 발생할 수 있는 문제들을 지니고있다.

이러한 모든 메소드들에 대해서는 상속을 염두해 둔 문서화 작업이 필요하다.

이 메소드는 이러 이러한 함수를 사용해서 이러 이렇게 동작한다와 같이 말이다.

그러나 이는 사용자가 API의 내부 구현을 몰라도 되고 사용만 하면 된다는

캡슐화의 내용과 상이하다.

그렇다 상속은 바로 이 캡슐화를 해치기 때문에 상속이 가능한 클래스라면

이러한 문서화가 필수적이다. 그렇지 않다면 상속을 금해야한다.

상속용 클래스에서 어떤 메소드를 protected로 선정해야 할까?

이에 대한 해답은 없다. 심사 숙고해서 어떤 메소드가 공개 돼야 할지 고민하고

이를 상속받은 클래스를 만들어 테스트해봐야한다.

상속을 허용하는 클래스가 지켜야하는 조건 중 하나는 다음과 같다.

상속용 클래스의 생성자는 직접적으로든 간접적으로든 재정의 가능 메서드를 호출해서는 안 된다.

이는 자바의 클래스가 상속을 받았을 때 어떤 식으로 동작하는지 생각해보면 쉽다.

// 재정의 가능 메서드를 호출하는 생성자 - 따라 하지 말 것! (115쪽)
public class Super {
    // 잘못된 예 - 생성자가 재정의 가능 메서드를 호출한다.
    public Super() {
        overrideMe();
    }

    public void overrideMe() {
    }
}

import java.time.Instant;

// 생성자에서 호출하는 메서드를 재정의했을 때의 문제를 보여준다. (126쪽)
public final class Sub extends Super {
    // 초기화되지 않은 final 필드. 생성자에서 초기화한다.
    private final Instant instant;

    Sub() {
        instant = Instant.now();
    }

    // 재정의 가능 메서드. 상위 클래스의 생성자가 호출한다.
    @Override public void overrideMe() {
        System.out.println(instant);
    }

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

Super 클래스와 이를 상속한 Sub 클래스이다. 이름부터 그렇다.

Super 클래스는 constructor에서 overrideMe 메소드를 호출한다.

다시 Sub 클래스로 내려와서 살펴보면 Sub의 재정의 된 overrideMe는

Sub 클래스의 필드를 출력하게 바뀌었다.

Sub 클래스의 객체를 생성하고 overrideMe를 호출하면 instant가 두번 호출될 것 같지만
첫번째는 null 두번째는 제대로 호출된다.

이는 Sub의 생성자에서 super 생성자를 호출하는데 이 때 Super 클래스의 생성자에서

재정의 된 overrideMe를 호출하는데 이 때는 아직 Sub 클래스의 필드가 초기화 되지 않은 상태이다.

따라서 null 값을 출력하게 된다.

이런식으로 상속 가능한 클래스의 생성자에서 재정의 가능한 메소드를 호출해서는 안된다.

이와 마찬가지로 Cloneable과 Serializable을 구현한 클래스에서

clone과 readObject 같은 메소드의 내부에서 재정의 가능한 메소드를 호출해서도 안된다.

복사를 하기 이전 아직 초기화 되지 않은 필드를 호출하는 재정의 된 메소드의 호출로

예기치 못한 문제를 낳을 수 있다.

또한 Serializable의 메소드들은 private으로 선언하면 리플렉션에 의해 호출이 되지만

이를 상속해서 사용한다고 하면 하위 객체에서 이 메소드들이 무시 되기 때문에

protected로 선언해주어야한다.

상속이 심사숙고해서 짜여지지 않은 클래스에서 발생한다면 문제가 많다.

그렇다면 이를 해결할 방법은? 상속을 막으면 된다.

상속을 막는 방법은 클래스를 final로 선언하거나 생성자를 private으로 선언하고

이 클래스의 인스턴스를 제공해주는 스태틱 팩토리 메소드를 제공하는것이다.

상속을 대신해서 쓸만한 내용은 공통 인터페이스를 설계하고 이를 구현하는 구현체로써 사용하는 것이다.

인터페이스를 구현한 구현체가 아닌데 상속을 막으면 사용하기 불편한 경우가 많다.

이러면 어떻게 하느냐? 문서화를 잘하거나 메소드에서 다른 상속 가능한 메소드를 사용하지 않는 것이다.

야호! 상속 안해야지!!

Effective Java - item 19. 상속을 고려해 설계하고 문서화하라. 그러지 않았다면 상속을 금지하라

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