이펙티브 자바, 쉽게 정리하기 - item 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

이펙티브 자바, 쉽게 정리하기 - item 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

와일드 카드 타입을 사용해야 하는 이유

• 제네릭은 불공변이다.
  • 하위 혹은 상위 타입을 기본적으로는 포용하지 않게 되어있다.
  • 필요하다면, extends 혹은 super를 이용하면 된다.

static class StackWithGeneric<E> {
    private E[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public StackWithGeneric() {
        elements = (E[])  new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(E e) {
        ensureCapacity();
        elements[size++] = e;
    }

    /* 새로 추가된 메서드 */
    public void pushAll(Iterable<E> src) {
        for (E e : src) {
            push(e);
        }
    }

    public E pop() {
        if (size == 0) {
            throw new EmptyStackException();
        }

        E result = elements[size];
        elements[size] = null;

        return result;
    }

    private void ensureCapacity() {
        if(elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }

    @Override
    public String toString() {
        return "StackWithGeneric{" +
                "elements=" + Arrays.toString(elements) +
                ", size=" + size +
                '}';
    }
}

• pushAll이라는 메서드를 새로 추가하였다.

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

• 보기엔 별 문제 없어보인다.
• 그러나 다음 클라이언트 코드를 작성하면 에러가 난다.

불공변인 제네릭코드 예제

@Test
public void stackTest() {
    StackWithGeneric<Number> stack = new StackWithGeneric<>();
    List<Integer> integers = List.of(1, 2, 3);
    stack.pushAll(integers);
    System.out.println("stack = " + stack);
}

• 위 코드는 에러가 난다. Number 타입의 스택에 Integer는 하위타입이기에 들어갈 수 있다고 생각하지만, 제네릭이 불공변이어서 에러가 난다.

생산자 버전: 한정적 와일드 카드 타입을 통해 불공변 제네릭 유연하게 만들기

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

• pushAll()을 위와 같이 바꾸면, 더이상 에러가 나지 않는다.
  • 단순히 E만 이용했을 때는 Number만 받을 수 있지만, 이제 Integer도 받을 수 있다.
• ? 와일드카드 타입으로 E를 상속한 아무 타입이나 받아줄 수 있다.
  • 제네릭의 불공변 때문에 이렇게 한정적 와일드카드 타입(? extends E)을 이용해주는 것이 좋다.

소비자 버전: 한정적 와일드 카드 타입을 통해 불공변 제네릭 유연하게 만들기

public void popAll(Collection<E> dst) {
    while(size > 0) {
        dst.add(pop());
    }
}

@Test
public void stackTest() {
    StackWithGeneric<Number> stack = new StackWithGeneric<>();
    List<Integer> integers = List.of(1, 2, 3);
    // produce
    stack.pushAll(integers);
    System.out.println("stack = " + stack);

    Collection<Object> objects = new ArrayList<>();
    stack.popAll(objects);
}

• popAll()도 위의 pushAll() 케이스와 비슷하게, 제네릭의 불공변 특성 때문에 에러가 나는 케이스이다.
• 불공변덕에 StackWithGeneric의 제네릭이 Number였어서 유연성 없이 Collection<Number> 타입만을 인수로 받을 수 있는데, 상위 타입인 Object가 와서 문제인 것이다.
• 소비자의 경우, 생산자와 다르게 상위 클래스로만 유연하게 확장해야 한다.
  • 클래스가 가진 컬렉션 필드에 수용할 때는 많은 정보 중 필요한 정보만 취사선택 하면 된다. (생산자 관점)
    • 정보가 더 많아서 나쁠 게 없다. (상위 타입은 하위 타입을 수용할 수 있다. 상속 덕에 필요한 정보가 이미 다 있다.)
  • 클래스가 가진 컬렉션 필드를 꺼내올 때는 해당 컬렉션이 가진 정보를 받아줄 객체가 필요하다. (소비자 관점)
    • 상위 객체만이 하위 객체를 받아줄 수 있다. (하위 타입은 상위 타입을 수용할 수 없다. 더 많은 정보가 필요하다.)
  • 그러므로 와일드카드에 super 키워드를 사용해야 한다.

public void popAll(Collection<? super E> dst) {
    while(size > 0) {
        dst.add(pop());
    }
}

• 위와 같이 작성하면 아무런 에러 없이 잘 작동된다.

생산자와 소비자 패턴에서 제네릭의 형태

• 상위 타입일수록 더 적은 정보를 가지고 있다. 하위 타입일수록 더 구체적인 다른 정보를 많이 가지고 있다.
• 생산자일 때는 하위 타입을 받아도 객체는 필요한 정보만 쓰면 되니, extends를 쓴다.
• 소비자일 때는 소비자의 정보를 받아줄 타입이 필요 하니, super를 쓴다.
• 만일 매개변수가 생산자와 소비자 둘의 역할을 모두 하면, 어느것을 써도 좋을 것이 없기 때문에 그냥 정확한 타입을 써야 한다.
  • 생산을 해야 하는데 상위 객체가 온다면 정보가 부족하고, 소비를 해야 하는데 하위 객체가

위와 같이 생산자(producer)에는 extends, 소비자(consumer)에는 super를 쓴다고 해서 PECS라고 부른다.

약간 특이한 케이스: Comparable의 제네릭 타입

• Comparable은 항상 소비자의 입장이다. PECS 원칙에 따라 super를 쓰는 것이 좋다.

super를 사용하지 않은 Comparable의 예

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

• 겉보기엔 크게 문제가 없어보인다.
• 그러나 아래 코드를 보면 생각이 좀 달라질 수 있다.

static class Student extends Person {
    private final int grade;

    public Student(String name, int age, int grade) {
        super(name, age);
        this.grade = grade;
    }
}

• Student 클래스는 Person 클래스와 공통 요소를 가지고 있어 Comparable<Student>를 구현한 것이 아니라, Comparable<Person>을 구현했다.
• 이럴 때는 Person 객체의 비교 기준으로 max 메서드를 사용하려면 아래와 같이 선언해주어야 한다.

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

• 이제 상위 객체 기준으로 Comparable을 상속하였어도 정상적으로 동작한다.

@Test
public void compareStudentTest() {
    Student student1 = new Student("john", 15, 1);
    Student student2 = new Student("jonna", 16, 2);
    Student student3 = new Student("kane", 14, 0);
    Student student4 = new Student("toto", 17, 3);
    Student student5 = new Student("momo", 15, 1);

    List<Student> students = new ArrayList<>(List.of(student1, student2, student3, student4, student5));

    System.out.println("students = " + students);
    System.out.println("max(students) = " + max(students));
}

결과

students = [Student{name='john', age=15, grade=1}, Student{name='jonna', age=16, grade=2}, Student{name='kane', age=14, grade=0}, Student{name='toto', age=17, grade=3}, Student{name='momo', age=15, grade=1}]
max(students) = Student{name='toto', age=17, grade=3}

• 가장 나이가 많은 학생인 toto가 잘 뽑힌 것을 볼 수 있다.

메서드 선언에 타입 매개변수가 한번만 나온다면 와일드 카드를 쓰자.

• 메서드 선언에 타입 매개변수가 단 한번만 나온다면, 와일드 카드를 썼을 때 그 의도가 더 명확하다.

@Test
public void methodSignatureWildcardTest() {
    List<String> strings = new ArrayList<>(List.of("a", "b", "c", "d", "e", "f"));
    swap(strings, 0, 1);
    System.out.println("strings = " + strings);
}

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

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

• 그냥 ? 와일드카드 타입만 쓰면, list.add()가 불가능하기에, showHelper()라는 도우미 메서드를 만들었다.
• 위와 같이 코드를 구성하면, API 외부로는 ? 와일드카드가 보이고, 내부에서는 <E> 타입을 쓰게 된다.

핵심 정리

• 조금 복잡하더라도 와일드카드 타입을 적용하면 API가 훨씬 유연해진다.
• 널리 쓰일 라이브러리엔 반드시 와일드카드 타입을 적용하자.
• 생산자에는 extends 소비자에는 super를 사용하는 PECS를 기억하자.