[제네릭]규칙28. 한정적 와일드카드를 써서 API유연성을 높여라

형인자 자료형은 불변 자료형이다. 불변 자료형이란 Type1과 Type2가 있을 때, List<Type1>과 List<Type2> 사이에는 어떤 상위-하위 자료형 관계도 성립할 수 없다는 것이다. 그러나 때로는 불변 자료형보다 높은 유연성이 필요할 때가 있다.

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이란 메소드를 추가한다고 생각해보자. 얼핏 보기에는 문제가 없어보이고, 스택의 자료형과 Iteable src가 가리키는 자료형이 일치하면 정상적으로 동작한다. 하지만 아래의 코드를 보면 오류를 발생시킨다.

Stack<Number> numberStack = new Stack<Number>(); Iterable<Integer> integers = ...; numberStack.pushAll(integers);

제네릭이 불변자료형이란걸 생각해보면 위의 코드가 왜 오류를 발생시키는 지 알것이다. 이러한 문제를 해결하기위해 자바에서는 와일드카드 자자료형이라는 특별한 형인자 자료형을 제공한다. 위 코드의 문제점을 해결하려면 pushAll의 인자 자료형을 "E의 Iterable"이 아니라 "E의 하위 자료형의 Iterable" 이라고 명시할 방법이 필요하다. 즉 Iterable<? extends E>라고 인자 자료형을 바꾸면 된다. 그렇다면 이 상황과 반대의 상황을 보자.

public void popAll(Collection<E> dst){ while( !isEmpty()) dst.add(pop()); } Stack<Number> numberStack = new Stack<Number>(); Collection<Object> objects = ...; numberStack.popAll(objects);

위의 예제역시 앞선 예제와 비슷한 오류가 발생한다. 이와 같은 문제를 해결하기 위해서는 popAll의 인자 자료형을 "E의 컬렉션"이 아니라 "E의 상위 자료형의 컬렉션"이라고 명시해야 한다. 즉 Collection<? super E>를 인자 자료형으로 주면된다.

 위의 두 상황을 토대로 생각해보면, 유연성을 최대화하려면, 객체 생산자나 소비자 구실을 하는 메서드 인자의 자료형은 와일드 카드 자료형으로 하라는 것이다. PECS(Produce - Extends , Consumer - Super) 약어를 기억하자. 즉 인자가 T 생상자라면 <? extends T>라고 하고, T 소비자라면 <? super T>라고 하라는 것이다. 하지만 반환값에는 와일드카드 자료형을 쓰면 안된다.

와일드 카드는 왜 쓰는 것이지? 와일드 카드 자료형은 받아야 할 자료형은 받을 수 있도록 해주고, 거부해야 할 자료형의 인자는 거부할 수 있도록 해주기 때문에 사용한다.