아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

[JoisFe]

아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

오해

서로 다른 타입 Type1과 Type2가 있을 때 List<Type1>은 List<Type2>의 상위 타입도 하위 타입도 아니다.

• 매개 변수화는 불공변 (아이템 28. 배열보다는 리스트를 사용하라. #59 참고)
• List<String>은 List<Object>의 하위 타입이 아니라는 뜻
• List<Object>에는 어떤 객체든 넣을 수 있지만 List<String>은 문자열만 넣을 수 있음
• 즉 List<String>은 List<Object>가 하는일을 제대로 수행하지 못하니 하위 타입이 될 수 없음 (리스코프 치환 원칙에 어긋남 -> 아이템 10. equals는 일반 규약을 지켜 재정의하라 #26 참고)

불공변 방식으로 인한 문제점

Stack의 public API를 추려보면

public class Stack<E> {
  public Stack();
  public void push(E e);
  public E pop();
  public boolean isEmpty();
}

여기에 일련의 원소를 스택에 넣는 메서드를 추가해야 하는 상황이라 가정해보자

public void pushAll(Iterable<E> src) {
  for (E e : src)
    push(e);
}

먼저 Stack 클래스를 상속하여 새로운 pushAll 메서드를 확장하기 위해 CustomStack을 구현

public class CustomStack<E> extends Stack<E> {

    public void pushAll(Iterable<E> src) {
        for (E e : src) {
            push(e);
        }
    }
}

public class Main {

    public static void main(String[] args) {
        CustomStack customStack = new CustomStack<>();

        Iterable<String> strings = List.of("abc", "def");
        customStack.pushAll(strings);
    }
}

• 위의 메서드는 깨끗이 컴파일되지만 완벽하지 않음.
• Iterable src 원소 타입이 스택의 원소 타입과 일치하면 잘 작동함

그럼 Stack<Number>로 선언한 후 pushAll(intVal) 호출 시 무슨일이 발생하는지 알아보면 (intVal은 Integer 타입)

public class Main {

    public static void main(String[] args) {
        CustomStack<Number> customStack = new CustomStack<>();

        Iterable<Integer> integers = List.of(1, 2, 3);
        customStack.pushAll(integers);
    }
}

잘못된 생각을 하면 Integer는 Number의 하위 타입이니 잘 동작할 것으로 예상하나
실제로는 위의 오류를 보이며 컴파일이 되지 않는다.

• 매개변수화 타입이 불공변이기 때문이다.

해결책 --> 불공변 방식보다 유연한 무언가...

자바에서는 위의 상황에 대처할 수 있는 한정적 와일드카드 타입이라는 특별한 매개변수화 타입을 지원.

한정적 와일드카드 타입

Iterable<E> --> Iterable<? extends E>

• pushAll의 입력 매개변수 타입은 E의 Iterable이 아니라 E의 하위타입의 Iterable이 되어야 함.

이제 위의 문제인 코드를 수정해보면

public void pushAll(Iterable<? extends E> src) {
        for (E e : src) {
            push(e);
        }
    }

이제 위의 문제의 코드는 문제 없이 컴파일 된다.
해당 코드로 수정으로 인해 CustomStack은 물론 이를 사용하는 클라이언트 코드도 말끔히 컴파일 됨.

CustomStack과 클라이언크 모두 깔끔히 컴파일 --> 모든 것이 타입 안전하다!!

스터디원 분들 위 방식대로 popAll() 메서드 또한 구현해보길 바랍니다. !!

• 당연히 불공변 방식의 문제를 깨닫고 --> 한정적 와일드 카드 방식으로 해결해보는 방법으로 진행한다면 더욱 좋겠죠^^

결론

유연성을 극대화하려면 원소의 생상자나 소비자용 입력 매개변수에 와일드카드 타입을 사용하라!!

와일드카드 타입이 굳이 필요없는 경우, 사용하지 말아야 하는 경우

입력 매개변수가 생산자와 소비자 역할을 동시에 하는 경우

• 타입을 정확히 지정해야 하는 상황이므로 와일드카드 타입을 쓰지 말아야함

와일드카드 타입을 사용해야 하는 경우

• PECS(producer-extends, consumer-super) (Get and Put Principle 이라고도 부름)
  • 매개변수화 타입 T가 생산자라면 <? extends T>를 사용하고 소비자라면 <? super T>를 사용하라

위 원칙을 통해 이전 아이템에서 설명한 메서드와 생성자 선언을 다시 살펴보면 (#59 참고)

public Chooser(Collection<T> choices)

위 생성자로 넘겨지는 choices 컬렉션은 T 타입의 값을 생산하기만 하니 (그리고 나중을 위해 저장) T를 확장하는 와일드카드 타입을 사용해 선언하는 것이 좋음

public Chooser(Collection<? extends T> choices)

위 처럼 수정하면 생기는 실질적 차이?

• Chooser<Number>의 생성자에 List<Integer>를 넘기고 싶다고 가정해보자
• 수정 전 생성자로는 컴파일조차 되지 않음
• 한정적 와일드카드 타입으로 수정한 후 생성자에는 문제가 사라짐

public static <E> Set<E> union(Set<E> s1, Set<E> s2)

s1과 s2 모두 E의 생산자 이므로 PECS 공식에 따라 수정해보면

public static <E> Set<E> union(Set<? extends E> s1, Set<? extends E> s2)

마찬가지로 위처럼 수정하면 이전에 컴파일되지 않던 아래 코드도 말끔히 컴파일이 됨!

Set<Integer> integers = Set.of(1, 3, 5);
Set<Double> doubles = Set.of(2.0, 4.0, 6.0);

Set<Number> numbers = union(integers, doubles);

클래스 사용자가 와일드카드 타입을 신경 써야 한다면 해당 API에 문제가 있을 가능성이 크다

• 제대로만 사용한다면 클래스 사용자는 와일드카드 타입이 쓰였다는 사실조차 의식하지 못할 것
• 받아들여야 할 매개변수를 받고 거절해야 할 매개변수는 거절하는 작업이 알아서 이뤄짐

자바 8 이전의 컴파일 문제

• 위 코드는 자바 8부터 제대로 컴파일 됨
• 자바 7 까지는 타입 추론 능력이 충분히 강력하지 못해 문맥에 맞는 반환 타입 (혹은 목표 타입)을 명시해야 했음
• 앞 코드 union 호출의 목표 타입은 Set인데 자바 7 까지는 이 코드를 컴파일 하면 문제가 일어났음

해결책

• 컴파일러가 올바른 타입을 추론하지 못해서 생긴 문제점
• --> 언제든 명시적 타입 인수 (explicit type argument)를 사용해서 타입을 알려주면 됨
• 목표 타이핑 (target typing)은 자바 8부터 지원
• 명시적 타입 인수 코드는 코드를 지저분하게 하는 문제가 있었지만 자바 8부터 해결

// 명시적 타입 인수 사용
Set<Number> numbers = Union.<Number>union(integers, doubles);

public static <E extends Comparable<E>> E max(List<E> list)

위 코드를 좀 더 다듬으면

public static <E extends Comparable<? super E>> E max(List<? extends E> list)

가 된다.

• 이번 경우 PECS 공식을 두번 적용한 사례
• 입력 매개변수에서는 E 인스턴스를 생산하므로 원래의 List<E>를 List<? extends E>로 수정
• 원래 선언에서는 E가 Comparable<E>를 확장한다고 정의했는데 이 때 Comparable<E>는 E 인스턴스를 소비함 (그리고 선후 관계를 뜻하는 정수를 생산)
• 그래서 매개변수화 타입 Comparable<E>를 한정적 와일드카드 타입인 Comparable<? super E>로 대체
• Comparable은 언제나 소비자이므로 일반적으로 Comparable<E> 보다는 Comparable<? super E>를 사용하는 편이 나음
• Comparator 또한 마찬가지 일반적으로 Comparator<E> 보다는 Comparator<? super E>를 사용하는 편이 나음

위 처럼 수정하면 생기는 실질적 차이?

List<ScheduledFuture<?>> scheduledFutures = ...;

위 코드의 리스트는 오직 수정된 max 로만 처리할 수 있다.

수정 전 max가 해당 리스트를 처리할 수 없는 이유

• (java.util.concurrent 패키지의) ScheduledFuture가 Comparable를 구현하지 않았기 때문에
• ScheduledFuture는 Delayed의 하위 인터페이스이고, Delayed는 Comparable를 확장했음
• 즉 ScheduledFuture의 인스턴스는 다른 ScheduledFuture 인스턴스뿐 아니라 Delayed 인스턴스와도 비교할 수 있어서 수정 전 max가 이 리스트를 거부함.

정리하면 Comparable 혹은 Comparator를 직접 구현하지 않고, 직접 구현한 다른 타입을 확장한 타입을 지원하기 위해 와일드카드가 필요

복잡할 수 있으니 위의 코드를 정리해보면

public interface Comparable<E>
public interface Delayed extends Comparable<Delayed>
public interface ScheduledFuture<V> extends Delayed, Future<V>

타입 매개변수와 와일드카드 둘 중 어느 것을 사용해도 되는 경우

타입 매개변수와 와일드카드에는 공통되는 부분이 있어 메서드 정의시 둘 중 아무거나 사용해도 괜찮을 때가 많다

주어진 리스트에서 명시한 두 인덱스의 아이템들을 교환하는 정적 메서드를 구현한 두가지 방식

1. 비한정적 타입 매개변수 (아이템 30. 이왕이면 제네릭 메서드로 만들라 #57 참고)

public static <E> void swap(List<E> list, int i, int j);

2. 비한정적 와일드카드

public static void swap(List<?> list, int i, int j);

Q) 위 방식 중 어떤 선언이 나을까?

1. public API라면 간단한 두 번째가 나음

• 어떤 리스트든 이 메서드에 넘기면 명시한 인덱스의 원소들을 교환해 줄 것이기 때문
• 신경 써야 할 타입 매개변수도 없음

기본 규칙

• 메서드 선언에 타입 매개변수가 한 번만 나오면 와일드카드로 대체하라
• 이때 비한정적 타입 매개변수라면 비한정적 와일드카드로 바꾸고
• 한정적 타입 매개면수라면 한정적 와일드카드로 바꾸면 됨

2. 두번째 swap 선언에 문제가 있는데 아주 직관적으로 구현한 코드가 컴파일 되지 않는다는 점

public static void swap(List<?> list, int i, int j) {
  list.set(i, list.set(j, list.get(i)));
}

위 코드르 컴파일시 별로 도움이 되지 않는 오류 메시지가 나옴

방금 꺼낸 원소를 리스트에 다시 넣을 수 없는 충격적인 상황이 발생한다. 이유는 ???

• 리스트의 타입이 List 인데 List에는 null 외에는 어떠한 값도 넣을 수 없기 때문이다 (아이템 26. 로 타입은 사용하지 말라 #49 참고)

해결책

다행히도 런타임 오류를 낼 가능성이 있는 해결 방법인 형변환이나 로 타입을 사용하지 않고도 가능하다

• 와일드카드 타입의 실제 타입을 알려주는 메서드를 private 도우미 메서드로 따로 작성하여 활용하는 방법
• 실제 타입을 알아내려면 이 도우미 메서드는 제네릭 메서드여야 함

public static void swap(List<?> list, int i, int j) {
  swapHelper(list, i, j);
}

public static <E> void swapHelper(List<E> list, int i, int j) {
  list.set(i, list.set(j, list.get(i)));
}

• swapHelper 메서드는 리스트가 List 임을 알고 있기 때문에 이 리스트에서 꺼낸 값의 타입은 항상 E 이고, E 타입의 값이라면 이 리스트에 넣어도 안전함을 알고 있다

따라서 최종적으로 깔끔히 컴파일됨을 확인할 수 있을것이다.

결과

1. 외부에서는 와일드카드 기반의 멋진 선언을 유지할 수 있었음
2. swap 메서드를 호출하는 클라이언트는 복잡한 swapHelper의 존재를 모른 채 그 혜택을 누림

정리

1. 불공변이 매개변수화는 너무 유연하지 못해 --> 와일드카드 타입을 적용해보자! (API 유연성을 높이자)
2. PECS 공식을 기억하자 (특정 사람들은 이 공식을 좋게 보지 않는 것 같음...)