item 52 leekyunghee - JAVA-JIKIMI/EFFECTIVE-JAVA3 GitHub Wiki

• 다음은 컬렉션을 집합, 리스트, 그 외로 구분하고자 만든 프로그램이다.

// 코드 52-1 컬렉션 분류기 - 오류! 이 프로그램은 무엇을 출력할까? (312쪽)
public class CollectionClassifier {
    public static String classify(Set<?> s) {
        return "집합";
    }

    public static String classify(List<?> lst) {
        return "리스트";
    }

    public static String classify(Collection<?> c) {
        return "그 외";
    }

    public static void main(String[] args) {
        Collection<?>[] collections = {
                new HashSet<String>(),
                new ArrayList<BigInteger>(),
                new HashMap<String, String>().values()
        };

        for (Collection<?> c : collections)
            System.out.println(classify(c));
    }
}

• 실제로 실행해보면 "그 외"만 세번 연달아 출력한다.
• 다중정의 (overloading, 오버로딩)된 세 classify 중 어느 메서드를 호출할지가 컴파일 타임에 정해지기 때문이다.
• 컴파일 타임에는 for문 안의 c는 항상 Collection<?> 타입이다. 런타임에는 매번 달라지지만, 호출할 메서드를 선택하는 데는 영향을 주지 못한다.
• 컴파일 타임의 매개변수 타입을 기준으로 항상 세 번째 메서드인 classify(Collection<?>)만 호출하는 것이다.

이처럼 직관과 어긋나는 이유는 재정의한 메서드는 동적으로 선택되고 다중정의한 메서드는 정적으로 선택되기 때문이다.

메서드를 재정의했다면 해당 객체의 런타임 타입이 어떤 메서드를 호출할지의 기준이 된다.

메서드 재정의란 상위 클래스가 정의한 것과 똑같은 시그니처의 메서드를 하위 클래스에서 다시 정의한 것을 말한다.

메서드를 재정의 한 다음 '하위 클래스의 인스턴스'에서 그 메서드를 호출하면 재정의한 메서드가 실행된다. 컴파일 타임에 그 인스턴스의 타입이 무엇이었냐는 상관없다.

// 재정의된 메서드 호출 메커니즘 (313쪽, 코드 52-2의 일부)

class Wine {
    String name() { return "포도주"; }
}

class SparklingWine extends Wine {
    @Override String name() { return "발포성 포도주"; }
}

class Champagne extends SparklingWine {
    @Override String name() { return "샴폐인"; }
}

// wine 클래스에 정의된 name 메서드는 하위 클래스인 SparklingWine, Champagne에서 재정의된다. 
// "포도주", "발포성 포도주", "샴폐인"을 차례로 출력한다. 
// for문에서의 컴파일 타임 타입이 모두 wine인 것에 무관하게 항상 '가장 하위에서 정의한' 재정의 메서드가 실행되는 것이다. 
public class Overriding {
    public static void main(String[] args) {
        List<Wine> wineList = List.of(
                new Wine(), new SparklingWine(), new Champagne());

        for (Wine wine : wineList)
            System.out.println(wine.name());
    }
} 

선택은 컴파일 타임에, 오직 매개변수의 컴파일타임 타입에 의해 이뤄진다.

코드 52-1의 CollectionClassifier 예에서 프로그램의 원래 의도는 매개변수의 런타임 타입에 기초해 적절한 다중정의 메서드로 자동 분배하는 것이었다. 코드 52-2의 Wine 예에서의 name 메서드와 똑같이 말이다.

• 다중정의하는 대신 메서드 이름을 다르게 지어주는 길도 항상 열려 있으니 말이다.

ObjectOutputStream 예시

• 이 클래스의 write 메서드는 모든 기본 타입과 일부 참조 타입용 변형을 가지고 있다. 그런데 다중정의가 아닌 모든 메서드에 다른 이름을 지어주는 길을 택했다.
• writeBoolean(boolean), writeInt(int), writeLong(long) 같은 식이다.
• 이 방식이 다중정의보다 나는 또 다른 점은 read 메서드의 이름과 짝을 맞추기 좋다는 것이다. ObjectInputStream 클래스의 read 메서드는 실제로도 readBoolean(boolean), readInt(int), readLong(long) 이렇게 되어 있다.

• 정적 팩터리라는 대안을 활용할 수 있는 경우가 많다.
• 또한 생성자는 재정의 할 수 없으니 다중정의와 재정의가 혼용될 걱정은 넣어둬도 된다.
• 여러 생성자가 같은 수의 매개변수를 받아야 하는 경우를 완전히 피해갈 수는 없을 테니 그럴 때를 대비해 안전 대책을 배워두면 도움이 될 것이다.

매개변수 수가 같은 다중정의 메서드가 많더라도 그중 어느 것이 주어진 매개변수 집합을 처리할지가 명확히 구분된다면 헷갈릴 일은 없을 것이다.

즉 매개변수 중 하나 이상이 "근본적으로 다르다" 면 헷갈릴 일이 없다. 근본적으로 다르다는 건 두 타입의 값을 서로 어느 쪽으로든 형변환할 수 없다는 뜻이다. 이 조건만 충족하면 어느 다중정의 메서드를 호출할지가 매개변수들의 런타임 타입만으로 결정된다.

• 자바 4까지는 모든 기본 타입이 모든 참조 타입과 근본적으로 달랐지만 자바 5에서 오토박싱이 도입되면서 평화롭던 시대가 막을 내렸다.

핵심 정리

일반적으로 매개변수 수가 같을 때는 다중정의를 피하는게 좋다. 
특히 생성자라면 이 조언을 따르기가 불가능할 수있다. 그럴 때는 헷갈릴 만한 매개변수는 형변환하여 정확한 다중정의 메서드가 선택되도록 해야 한다. 
이것이 불가능하면 예컨대 기존 클래스를 수정해 새로운 인터페이스를 구현해야할 때는 같은 객체를 입력받는 다중 정의 메서드들이 모두 동일하게 동작하도록 만들어야 한다.