JDK가 제공하는 제네릭 타입과 메소드를 사용하는 일은 일반적으로 쉬운 편이 아니지만, 제네릭 타입을 새로 만드는 일은 조금 더 어렵다. 그래도 배워두면 그만한 값어치는 충분히 한다. 단순한 스택 코드를 살펴보자.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 | /* * Object 개반 스택 - 제네릭이 절실한 강력 후보! */ public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object e) { ensureCapacity(); elements[size++] = e; } public Object pop() { if (size == 0) throw new EmptyStackException(); Object result = elements[--size]; elements[size] = null; // 다 쓴 참조 해제 return result; } public boolean is Empty() { return size == 0; } private void ensureCapacity() { if (elements.length == size) elements = Arrays.copyOf(elements, 2 * size + 1); } } | cs |
위 클래스는 원래 제네릭 타입이어야 마땅하다. 일반 클래스를 제네릭 클래스로 만드는 첫 단계는 클래스 선언에 타입 매개변수를 추가하는 일이다. 이때 타입 이름으로는 보통 E를 사용한다. 코드에 쓰인 Object를 적절한 타입 매개변수로 바꾸고 컴파일해보자.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | // 제네릭으로 가는 첫 단계 - 컴파일되지 않는다. public class Stack<E> { private E[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY = 16; public Stack() { elements = new E[DEFAULT_INITIAL_CAPACITY]; } public void push(E e) { ensureCapacity(); elements[size++] = e; } public E pop() { if (size == 0) throw new EmptyStackException(); E result = elements[--size]; elements[size] = null; // 다 쓴 참조 해제 return result; } ... // isEmpty와 ensureCapacity 메소드는 그대로다. } | cs |
이 클래스는 오류가 발생하는데, E와 같은 실체화 불가 타입으로는 배열을 만들 수 없기 때문이다. 배열을 사용하는 코드를 제네릭으로 만들려 할 때는 이 문제가 항상 발목을 잡을 것이다.
첫 번째 해결책은 제네릭 배열 생성을 금지하는 제약을 대놓고 우회하는 방법이다. Object 배열을 생성한 다음 제네릭 배열로 형변환하면 컴파일러는 오류 대신 경고를 내보낼 것이다. 이렇게도 할 수는 있지만 일반적으로 타입 안전하지 않다.
컴파일러가 이 프로그램이 타입 안전한지 증명할 방법이 없기에 직접 증명해야 한다. 현 예제에서 문제의 배열 elements는 private 필드에 저장되고, 클라이언트로 반환되거나 다른 메소드에 전달되는 일이 전혀 없으므로, 비검사 형변환은 확실히 안전하다. 비검사 형변환이 안전함을 직접 증명했다면 범위를 최소로 좁혀 @SuppressWarnings 애너테이션으로 해당 경고를 숨긴다. 이후에 Stack은 깔끔히 컴파일되고, 명시적으로 형변환하지 않아도 ClassCastException 걱정 없이 사용할 수 있게 된다.
1 2 3 4 5 6 7 8 | // 배열을 사용한 코드를 제네릭으로 만드는 방법 1 // 배열 elements는 push(E)로 넘어온 E 인스턴스만 담는다. // 따라서 타입 안전성을 보장하지만, // 이 배열의 런타임 타입은 E[]가 아닌 Object[]다! @SuppressWarings("unchecked") public Stack() { elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY]; } | cs |
제네릭 배열 생성 오류를 해결하는 두 번째 방법은 elements 필드의 타입을 E[]에서 Object[]로 바꾸는 것이다. 배열이 반환한 원소를 E로 형변환하면 오류 대신 경고가 뜬다.
E는 실체화 불가 타입이므로 컴파일러는 런타임에 이뤄지는 형변환이 안전한지 증명할 방법이 없다. 이번에도 마찬가지로 직접 증명하고 경고를 숨길 수 있다. 비검사 형변환을 수행하는 할당문에서만 숨겨보자.
1 2 3 4 5 6 7 8 9 10 11 12 | // 배열을 사용한 코드를 제네릭으로 만드는 방법 2 // 비검사 경고를 적절히 숨긴다. public E pop() { if (size == 0) throw new EmptyStackException(); // push에서 E 타입만 허용하므로 이 형변환은 안전하다. @SuppressWarnings("unchecked") E result = (E) elements[--size]; elements[size] = null; // 다 쓴 참조 해제 return result; } | cs |
첫 번째 방법은 가독성이 더 좋고 코드가 더 짧아 현업에서 선호되며 자주 사용된다. 배열의 타입을 E[]로 선언하여 오직 E 타입 인스턴스만 받음을 확실히 어필한다. 두 번째 방법이 배열에서 원소를 읽을 때마다 형변환을 해줘야 하는 것에 반해, 형변환을 배열 생성 시 단 한 번만 해주면 되서 이곳저곳에서 이 배열을 자주 사용하는 상황에 좋다. 하지만 E가 Object가 아닌 한 배열의 런타임 타입이 컴파일타임 타입과 달라 힙 오염(heap pollution)을 일으킨다. 힙 오염이 맘에 걸리는 프로그래머는 두 번째 방법을 고수하기도 한다.
배열보다는 리스트를 우선하라곤 했지만 사실 제네릭 타입 안에서 리스트를 사용하는 게 항상 가능하지도, 꼭 더 좋은 것도 아니다. 자바가 리스트를 기본 타입으로 제공하지 않으므로 ArrayList 같은 제네릭 타입도 결국은 기본 타입인 배열을 사용해 구현해야 한다. 또한 HashMap 같은 제네릭 타입은 성능을 높일 목적으로 배열을 사용하기도 한다.
클라이언트에서 직접 형변환해야 하는 타입보다 제네릭 타입이 더 안전하고 쓰기 편하다. 그러니 새로운 타입을 설계할 때는 형변환 없이도 사용할 수 있도록 하라. 그렇게 하려면 제네릭 타입으로 만들어야 할 경우가 많다. 기존 타입 중 제네릭이었어야 하는 게 있다면 제네릭 타입으로 변경하자. 기존 클라이언트에는 아무 영향을 주지 않으면서, 새로운 사용자를 훨씬 편하게 해주는 길이다.