다중정의 문제
재정의(overriding)한 메서드는 동적으로 선택되지만, 다중정의(overloading)한 메서드는 정적으로 선택된다.
즉, 다중정의된 메서드 사이에서는 객체의 런타임 타입은 전혀 중요하지 않다. 선택은 매개변수의 컴파일타임 타입에 의해 이뤄진다.
API 사용자가 매개변수를 넘기면서 어떤 다중정의 메서드가 호출될지 모른다면 프로그램이 오동작하기 쉽다.
그러니 다중정의가 혼동을 일으키는 상황을 피해야 한다.
다중정의가 혼란을 주는 상황을 피하는 방법
1. 매개변수 수가 같은 다중정의는 만들지 말고, 메서드 이름을 다르게 지어주자.
안전하고 보수적으로 가려면 매개변수 수가 같은 다중정의는 만들지 말자.
가변인수를 사용하는 메서드라면 다중정의는 아예 하지 말아야 한다. (예외는 아이템 53을 참고)
이런 상황에서는 다중정의를 만들지 말고, 메서드 이름을 다르게 지어주자.
2. 생성자의 경우, 정적 팩터리를 사용하거나 근본적으로 다른 타입을 사용하자.
생성자의 경우, 이름을 다르게 지을 수 없기 때문에 무조건 다중정의가 된다.
이때는 정적 팩터리가 대안이 될 수 있는 경우가 많다.
그래도 여러 생성자가 같은 수의 매개변수를 받아야 하는 경우를 완전히 피해갈 수 없다면, 매개변수 중 하나 이상이 근본적으로 다르다(radically different) 면 헷갈일 일이 없다. 근본적으로 다르다는 건 null이 아닌 두 타입의 값을 서로 어느 쪽으로든 형변환할 수 없다는 뜻이다. 이 조건을 만족하면 매개변수들의 런타임 타입만으로 결정이 되어 혼란을 주는 주된 원인이 사라진다.
3. 서로 다른 함수형 인터페이스라도 같은 위치의 인수로 받아서는 안 된다.
서로 다른 함수형 인터페이스라도 서로 근본적으로 다르지 않기 때문이다.
🔖 핵심 정리
프로그래밍 언어가 다중정의를 허용한다고 해서 다중정의를 꼭 활용하란 뜻은 아니다.
일반적으로 매개변수 수가 같을 때는 다중정의를 피하는 게 좋다.
상황에 따라, 특히 생성자라면 이 조언을 따르기가 불가능할 수 있다. 그럴 때는 헷갈릴 만한 매개변수는 형변환하여 정확한 다중정의 메서드가 선택되도록 해야 한다.
이것이 불가능하면, 예컨대 기존 클래스를 수정해 새로운 인터페이스를 구현해야 할 때는 같은 객체를 입력받는 다중정의 메서드들이 모두 동일하게 동작하도록 만들어야 한다. 그렇지 않으면 프로그래머들은 다중정의된 메서드나 생성자를 효과적으로 사용하지 못할 것이고, 의도대로 동작하지 않는 이유를 이해하지도 못할 것이다.
