목차
· 아이템 26. 로 타입은 사용하지 말라
· 아이템 27. 비검사 경고를 제거하라
· 아이템 28. 배열보다는 리스트를 사용하라
· 아이템 29. 이왕이면 제네릭 타입으로 만들라
· 아이템 30. 이왕이면 제네릭 메서드로 만들라
· 아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라
· 아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라
· 아이템 33. 타입 안전 이종 컨테이너를 고려하라
· 옮긴이의 말
아이템 26. 로 타입은 사용하지 말라
핵심 정리
· 로 타입을 사용하면 런타임에 예외가 날 수 있으니 사용하면 안 된다.
- 로 타입은 제네릭이 도입되기 이전 코드와의 호환성을 위해 제공될 뿐이다.
· Set<Object>는 어떠 타입의 객체도 저장할 수 있는 매개변수화 타입이고, Set<?>는 모종의 타입 객체만 저장할 수 있는 와일드카드 타입이다. 각각을 임의의 객체를 허용하는 매개변수화 타입, 비한정적 와일드카드 타입으로 부를 수 있다.
- 이들의 로 타입인 Set은 제네릭 타입 시스템에 속하지 않는다. Set<Object>와 Set<?>은 안전하지만, 로 타입은 안전하지 않다.
제네릭 관련 용어 정리
· 클래스와 인터페이스 선언에 대해 타입 매개변수가 쓰이면 이를 제네릭 클래스 혹은 제네릭 인터페이스라 한다.
ex) List 인터페이스는 원소 타입을 나타내는 타입 매개변수 E를 받는다.
· 제네릭 클래스와 제네릭 인터페이스를 통틀어 제네릭 타입이라 한다.
- 각각의 제네릭 타입은 일련의 매개변수화 타입을 정의한다. 먼저 클래스(혹은 인터페이스) 이름이 나오고 이어서 꺾쇠괄호 안에 실제 타입 매개변수들을 나열한다.
ex) List<String>은 원소의 타입이 String인 리스트를 뜻하는 매개변수화 타입이다. 여기서 정규(formal) 타입 매개변수 E에 해당하는 실제 타입 매개변수는 String이다.
· 로 타입(raw type)이란 제네릭 타입에서 타입 매개변수를 전혀 사용하지 않을 때를 말한다.
- 로 타입의 용도: 제네릭이 도래하기 전 코드와 호환되도록 하기 위해 제공된다.
ex) List<E>의 로 타입은 List이다.
로 타입의 문제점
제네릭을 지원하기 전 컬렉션은 다음과 같이 선언했다.
// Stamp 인스턴스만 취급한다.
private final Collection stamps= ...;
· 문제점: 이 코드를 사용하면 실수로 도장 대신 동전을 넣어도 아무 오류 없이 컴파일되고 실행된다.
// 실수로 동전을 넣는다.
stamps.add(new Coin(...));
그리고 동전을 다시 꺼내기 전에는 오류를 알아채지 못한다.
- 오류는 가능한 발생 즉시, 이상적으로는 컴파일할 때 발견하는 것이 좋다.
// 반복자의 로 타입 - 따라 하지 말 것!
for(Iterator i = stamps.iterator(); i.hasNext();){
Stamp stamp = (Stamp) i.next(); // ClassCastException을 던진다.
stamp.cancel()
}
로 타입의 문제의 해결 - 제네릭의 사용
제네릭을 활용하면 이 정보가 주석이 아닌 선언 자체에 녹아든다.
// 매개변수화된 컬렉션 타입 - 타입 안정성 확보!
private final Collection<Stamp> stamps= ...;
이렇게 선언하면 컴파일러는 stamp에는 Stamp의 인스턴스만 넣어야 함을 컴파일러가 인지한다. 그리고, 엉뚱한 인스턴스를 넣으려 하면 컴파일 오류가 발생하며 무엇이 잘못됐는지 정확히 알려준다.
- 실제로 현업에서 BigDecimal용 컬렉션에 BigInteger를 넣는 등의 실수는 종종 일어난다.
stamps.add(new Coin(...)); // incompatible types: Coin cannot be converted to Stamp
· 컴파일러는 컬렉션에서 원소를 꺼내는 모든 곳에 보이지 않는 형변환을 추가하여 절대 실패하지 않음을 보장한다.
· 로 타입을 쓰면 제네릭이 안겨주는 안전성과 표현력을 모두 잃게 되므로, 절대 사용하면 안된다.
임의의 객체를 허용하는 매개변수화 타입
· List와 List<Object>의 차이점: List는 제네릭 타입에서 완전히 발을 뺀 것이고, List<Object>는 모든 타입을 허용한다는 의사를 컴파일러에 명확히 전달한 것이다.
· 매개변수로 List를 받는 메서드에 List<String>을 넘길 수 있지만, List<Object>를 받는 메서드에는 넘길 수 없다. 이는 제네릭의 하위 타입 규칙 때문이다. 즉, List<String>은 로 타입인 List의 하위 타입이지만, List<Object>의 하위 타입은 아니다(아이템 28).
· List<Object>처럼 임의 객체를 허용하는 매개변수화 타입은 괜찮다.
- List<Object> 같은 매개변수화 타입을 사용할 때와 달리 List 로 타입을 사용하면 타입 안전성을 잃게 된다.
예시 1 - 로 타입과 임의의 객체를 허용하는 매개변수화 타입
둘의 차이를 확인하기 위해 예시를 살펴보자. 아래는 로 타입 List를 사용하는 코드다.
public static void main(String[] args) {
List<String> strings = new ArrayList<>();
unsafeAdd(strings, Integer.valueOf(42));
String s = strings.get(0); // 컴파일러가 자동으로 형변환 코드를 넣어준다.
}
private static void unsafeAdd(List list, Object o) {
list.add(o);
}
이 코드는 컴파일은 되지만, unchecked 경고가 발생한다. 그리고, 이대로 실행하면 strings.get(0)의 결과를 형변환하려 할 때 ClassCastException을 던진다.
해당 로 타입 List를 매개변수화 타입인 List<Object>로 바꾸면 오류 메시지가 출력되며 컴파일조차 되지 않는다.
예시 2 - 로 타입과 비한정적 와일드카드 타입
아래는 2개의 집합(Set)을 받아 공통 원소를 반환하는 메서드다. 모르는 타입의 원소도 받는 로 타입을 사용한다.
static int numElementsInCommon(Set s1, Set s2){
int result = 0;
for(Object o1 : s1){
if(s2.contains(o1)){
result++;
}
}
return result;
}
이 메서드는 동작은 하지만 로 타입을 사용해 안전하지 않다. 따라서 비한정적 와일드카드 타입(unbounded wildcard type)을 대신 사용하는 게 좋다.
· 제네릭 타입을 쓰고 싶지만 실제 타입 매개변수가 무엇인지 신경 쓰고 싶지 않을 때는 물음표(?)를 사용하자.
- 이것은 어떤 타입이라도 담을 수 있는 가장 범용적인 Set 타입이다.
다음은 비한정적 와일드카드 타입을 사용한 예시다.
static int numElementsInCommon(Set<?> s1, Set<?> s2) {...}
· 로 타입(Set)과 비한정적 와일드카드 타입의 차이점: 와일드카드 타입은 안전하며, 유연하다.
- 로 타입 컬렉션에는 아무 원소나 넣을 수 있으니 타입 불변식을 훼손하기 쉽다.
- 반면, Collection<?>에는 null 외에는 어떤 원소도 넣을 수 없다. 다른 원소를 넣으려 하면 컴파일할 때 오류가 발생한다.
즉, 컬렉션의 타입 불변식을 훼손하지 못하게 막았다. 어떤 원소도 Collection<?>에 넣지 못하게 했으며 컬렉션에서 꺼낼 수 있는 객체의 타입도 전혀 알 수 없다. 이러한 제약을 받아 들일 수 없다면, 제네릭 메서드(아이템 30)나 한정적 와일드카드 타입(아이템31)을 사용하면 된다.
로 타입이 허용되는 사례
1. class 리터럴에는 로 타입을 써야 한다.
- 자바 명세는 class 리터럴에 매개변수화 타입을 사용하지 못하게 했다(배열과 기본 타입은 허용).
ex) List.class, String[].class, int.class는 허용하고 List<String>.class, List<?>, class는 허용하지 않는다.
2. instanceof 연산자는 비한정적 와일드카드 타입 이외의 매개변수화 타입에는 적용할 수 없다.
- 런타임에는 제네릭 타입이 지워지기 때문이다.
- 로 타입이든 비한정적 와일드카드 타입이든 instanceof는 완전히 똑같이 동작한다.
비한정적 와이들카드 타입의 꺾쇠괄호화 물음표는 아무런 역할 없이 코드만 지저분하게 만드므로, 차라리 로 타입을 쓰는 편이 깔끔하다. 다음은 제네릭 타입에 instanceof를 사용하는 올바른 예이다.
// o의 타입이 Set 임을 확인한 다음 Set<?> 로 형변환해야 한다
if( o instanceof Set ){ // raw 타입
Set<?> s = (Set<?>) o; // 와일드카드 타입 (컴파일러 경고가 뜨지 않는다)
}
아이템 27. 비검사 경고를 제거하라
핵심 정리
· 비검사 경고는 중요하니 무시하지 말자.
- 모든 비검사 경고는 런타임에 ClassCassException을 일으킬 수 있는 잠재적 가능성을 뜻한다. 최선을 다해 제거하자.
· 경고를 없앨 방법을 찾지 못하겠다면, 그 코드가 타입 안점함을 증명하고 가능한 한 범위를 좁혀 @SuppressWarnings("unchecked") 애너테이션으로 경고를 숨겨라. 그런 다음 경고를 출기기로 한 근거를 주석으로 남겨라.
제네릭과 컴파일러 경고
· 제네릭을 사용하기 시작하면 수많은 컴파일러 경고를 보게 될 것이다.
ex) 비검사 형변환 경고, 비검사 메서드 호출 경고, 비검사 매개변수화 가변인수 타입 경고, 비검사 변환 경고 등
· 대부분의 비검사 경고는 쉽게 제거할 수 있다.
코드를 다음처럼 잘못 작성했다고 가정하자.
Set<Lark> exaltation = new HashSet();
컴파일러는 무엇이 잘못됐는지 친절히 설명해준다.
컴파일러가 알려준 대로 수정하면 경고가 사라진다. 컴파일러가 알려준 타입 매개변수를 명시하지 않고, 자바 7부터 지원하는 다이아몬드 연산자(<>)만으로 해결할 수도 있다.
- 그러면 컴파일러가 올바른 실제 타입 매개변수를 추론해준다.
Set<Lark> exaltation = new HashSet<>();
· 할 수 있는 한 모든 비검사 경고를 제거하자. 모두 제거한다면 그 코드는 타입 안전성이 보장된다.
- 즉, 런타임에 ClassCastException이 발생할 일이 없고, 우리가 의도한 대로 잘 동작하리라 확신할 수 있다.
· 결과를 제거할 수는 없지만 타입 안전하다고 확실할 수 있다면 @SuppressWaringins("unchecked") 애너테이션을 달아 경고를 숨기자.
- 단, 타입 안전함을 검증하지 않은 채 경고를 숨기면 스스로에게 잘못된 보안 인식을 심어주는 꼴이다.
- 해당 애너테이션을 사용할 때면 그 경고를 무시해도 안전한 이유를 항상 주석으로 남겨야 한다.
· 안전하다고 검증된 비점사 경고를 숨기지 않고 그대로 두면, 진짜 문제를 알리는 새로운 경고가 나와도 제거하지 않은 수많은 거짓 경고 속에 파묻혀 눈치채지 못할 수 있다.
· @SuppressWaring 애너테이션은 지역변수부터 클래스 전체까지 어떤 선언에도 달 수 있지만, 가능한 좁은 범위에 적용하자.
- 보통은 변수 선언, 아주 짧은 메서드, 혹은 생성자가 될 것이다.
- 클래스 전체에 적용하면 자칫 심각한 경고를 놓칠 수 있다.
@SuppressWaring 애너테이션 사용 범위를 좁히는 예시
다음은 ArrayList에서 가져온 toArray 메서드다.
public <T> T[] toArray(T[] a) {
if( a.length < size )
return (T[]) Arrays.copyOf(elements, size, a.getClass());
System.arraycopy(elements, 0, a, 0, size);
if( a.length > size )
a[size] = null;
return a;
}
ArrayList를 컴파일하면 이 메서드에서 elements 요소에 unchecked cast 경고가 발생한다. 애너테이션은 선언에만 달 수 있기 때문에 return 문에는 달 수 없다. 메서드 전체에 달고 싶겠지만, 범위가 필요 이상으로 넓어진다.
대신에 반환값을 담을 지역변수를 하나 선언하고, 그 변수에 애너테이션을 달아주자.
public <T> T[] toArray(T[] a) {
if( a.length < size ){
// 생성한 배열과 매개변수로 받은 배열의 타입이 모두 T[] 로 같으므로
// 올바른 형변환이다
@SuppressWarnings("unchecked") T[] result =
(T[]) Arrays.copyOf(elements, size, a.getClass());
return result;
}
System.arraycopy(elements, 0, a, 0, size);
if( a.length > size )
a[size] = null;
return a;
}
· 이 코드는 깔끔하게 컴파일되고, 비검사 경고를 숨기는 범위도 최소로 좁혔다.
아이템 28. 배열보다는 리스트를 사용하라
핵심 정리
· 배열은 공변이다.
- Sub가 Super의 하위 타입이라면 Sub[]은 배열 Super[]의 하위 타입이 된다.
· 제네릭은 불공변이고, 타입 정보가 소거된다.
- 서로 다른 타입 Type1과 Type2가 있을 때, List<Type1>은 List<Type2>의 하위 타입도 아니고 상위 타입도 아니다.
· 그 결과 배열은 런타임에는 타입 안전하지만, 컴파일타임에는 그렇지 않다. 제네릭은 반대다.
· 그래서 둘을 섞어 쓰기란 쉽지 않다. 둘을 섞어 쓰다가 컴파일 오류나 경고를 만나면, 가장 먼저 배열을 리스트로 대체하는 방법을 적용해보자.
배열과 리스트의 차이
· 배열과 제네릭 타입에는 중요한 차이가 두 가지 있다.
1. 배열은 공변(covariant)이고, 제네릭은 불공변(invariant)이다.
- Sub가 Super의 하위 타입이라면 배열 Sub[]은 배열 Super[]의 하위 타입이 된다. 공변은 함께 변한다는 뜻이다.
즉, Object[]에 Integer[]을 대입할 수 있다. (자바의 설계 오류)
- 서로 다른 타입 Type1과 Type2가 있을 때, List<Type1>은 List<Type2>의 하위 타입도 아니고 상위 타입도 아니다.
List<String>은 List<Object>가 하는 일을 제대로 수행하지 못하니 하위 타입이 될 수 없다(리스코프 치환 원칙에 어긋난다. 아이템 10).
둘의 차이를 알아보기 위해 예시를 살펴보자. 다음은 허용되는 코드다.
// 런타임에 실패하다.
Object[] objectArray = new Long[1];
objectArray[0] = "타입이 달라 넣을 수 없다"; // ArrayStoreException
다음은 문법에 맞지 않는다.
// 컴파일되지 않는다.
List<Object> ol = new ArrayList<Long>(); // 호환되지 않는 타입
ol.add("타입이 달라 넣을 수 없다");
어느 쪽이든 Long용 저장소에 String을 넣을 수 없다. 다만 배열에서는 그 실수를 런타임에 알게 되지만, 리스트를 사용하면 컴파일할 때 바로 알 수 있다.
2. 배열은 실체화(reify)된다.
- 배열은 런타임에도 자신이 담기로한 원소의 타입을 인지하고 확인한다. 그래서 위에서 처럼 Long 배열에 String을 넣으려 하면 ArrayStoreException이 발생한다.
- 반면, 제네릭은 타입 정보가 런타임에는 소거(erasure)된다. 즉, 원소 타입을 컴파일타임에만 검사하며 런타임에는 알수조차 없다.
- 소거는 제네릭이 지원되기 전의 레거시 코드와 제네릭 타입을함께 사용할 수 있게 해주는 매커니즘이다.
· 이러한 차이로 배열과 제네릭은 잘 어우러지지 못한다.
- 예를들어 배열은 제네릭 타입, 매개변수화 타입, 타입 매개변수로 사용할 수 있다.
ex) new List<E>[], new List<String>[], new E[] 식으로 작성하면 컴파일할 때 제네릭 배열 생성 오류를 일으킨다.
제네릭 배열을 만들지 못하게 막은 이유
· 타입안전하지 않기 때문이다.
- 이를 허용한다면 컴파일러가 자동 생성한 형변환 코드에서 런타임에 ClassCastException이 발생할 수 있다.
- 이는 런타임에 ClassCastException이 발생하는 일을 막아주겠다는 제네릭 타입 시스템의 취지에 어긋난다.
TODO: 내용 추가
List<String>[] stringLists = new List<String>[1]; // (1)
List<Integer> intList = List.of(42); // (2)
Object[] objects = stringLists; // (3)
objects[0] = intList; // (4)
String s = stringLists[0].get(0); // (5)
public class Chooser {
private final Object[] choiceArray;
public Chooser(Collection choices) {
choiceArray = choices.toArray();
}
public Object choose() {
Random rnd = ThreadLocalRandom.current();
return choiceArray[rnd.nextInt(choiceArray.length)];
}
}public class Chooser<T> {
private final T[] choiceArray;
public Chooser(Collection<T> choices) {
choiceArray = choices.toArray();
}
// choose 메서드는 그대로
}public class Chooser<T> {
private final List<T> choiceList;
public Chooser(Collection<T> choices) {
choiceList = new ArrayList<>(choices);
}
public T choose() {
Random rnd = ThreadLocalRandom.current();
return choiceList.get(rnd.nextInt(choiceList.size()));
}
}
아이템 29. 이왕이면 제네릭 타입으로 만들라
핵심 정리
· 클라이언트에서 직접 형변환해야 하는 타입보다 제네릭 타입이 더 안전하고 쓰기 편하다.
· 따라서 새로운 타입을 설계할 때는 형변환 없이도 사용할 수 있도록 하라. 그렇게 하려면 제네릭 타입으로 만들어야 할 경우가 많다.
· 기존 타입 중 제네릭이었어야 하는 게 있다면 제네릭 타입으로 변경하자.
- 기존 클라이언트에는 아무런 영향을 주지 않으면서, 새로운 사용자를 훨씬 편하게 해주는 길이다(아이템 26).
예시 - Object 기반 스택
· 제네릭 타입을 새로 만드는 일은 조금 어렵다. 그래도 배워두면 그만한 값어치를 충분히 한다.
// 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 isEmpty() {
return size == 0;
}
private void ensureCapacity() {
if( elements.length == size )
elements = Arrays.copyOf(elements, 2*size + 1);
}
}
· 이 클래스는 원래 제네릭 타입이어야 마땅하다. 이 클래스를 제네릭으로 바꿔도 현재 버전을 사용하는 클라이언트에는 아무런 해가 없다.
- 오히려 지금 상태에서의 클라이언트는 스택에서 꺼낸 객체를 형변환해야 하는데, 이때 런타임 오류가 날 위험이 있다.
예시 - 제네릭 스택으로 가는 첫 단계
일반 클래스를 제네릭 클래스로 만들어보자.
1. 클래스 선언에 타입 매개변수를 추가한다.
위 코드에서는 스택이 담을 원소 타입 하나만 추가한다. 타입 이름으로 보통 E를 사용한다(아이템 68).
2. 두 코드에 쓰인 Object를 적절한 타입 매개변수로 바꾸고 컴파일해보자.
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 메서드는 그대로다.
}
이 단계에서 대체로 하나 이상의 오류나 경고가 발생한다. 위 코드도 아래 부분에서 오류가 발생한다. E와 같은 실체화 분가 타입으로는 배열을 만들 수 없기 때문이다.
elements = new E[DEFAULT_INITIAL_CAPACITY];
이렇게 배열을 사용하는 코드를 제네릭으로 만들려 할 때 해결책은 두 가지다.
오류 해결 방법 첫 번째, 제네릭 배열 생성을 금지하는 제약을 대놓고 우회하는 방법이다. Object 배열을 생성한 다음 제네릭 배열로 형변환하자.
- 이제 컴파일러는 오류 대신 경고를 내보낸다. 하지만 일반적으로 타입 안정하지 않은 방법이다.
elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
컴파일러는 이 프로그램이 타입 안전한지 증명할 방법이 없지만, 우리는 할 수 있다. 따라서 이 비검사 형변환이 프로그램의 타입 안전성을 해치지 않음을 우리 스스로 확인해야 한다.
문제의 배열 elements는 private 필드에 저장되고, 클라이언트로 반환되거나 다른 메서드에 전달되는 일이 전혀 없다. push 메서드를 통해 배열에 저장되는 원소의 타입은 항상 E다. 따라서 이 비검사 형변환은 확실히 안전하다.
비검사 형변환이 안전함을 직접 증명했다면, 범위를 최소로 좁혀 @SuppressWarings 애너테이션으로 해당 경고를 숨긴다(아이템 27). 이 예에서는 생성자가 비검사 배열 생성 말고는 하는 일이 없으니 생성자 전체에서 경고를 숨겨도 좋다.
// 배열 elements 는 push(E) 로 넘어온 E 인스턴스만 담는다
// 따라서 타입 안전성을 보장하지만,
// 이 배열의 런타임 타입은 E[] 가 아닌 Object[] 이다
@SuppressWarnings("unchecked")
public Stack() {
elements = (E[]) new Object[DEFAULT_INITIAL_CAPACITY];
}
오류 해결 방법 두 번째, elements 필드의 타입을 E[]에서 Object[]로 바꾼다.
- 이렇게 하면 첫 번째와는 다른 오류가 발생한다.
배열이 반환한 원소를 E로 형변환하면 오류 대신 오류 대신 경고가 뜬다. E는 실체화 불가 타입이므로 컴파일러는 럼타임에 이뤄지는 형변환이 안전한지 증명할 수 없다. 따라서 이번에도 우리가 직접 증명하고 경고를 숨길 수 있다.
pop 메서드 전체에서 경로를 숨기지 말고, 비검사 형변환을 수행하는 할당문에서만 숨겨보자.
// 비검사 경고를 적절히 숨긴다
public E pop() {
if( size == 0 ) throw new EmptyStackException();
// push 에서 E 타입만 허용하므로 이 형변환은 안전하다
@SuppressWarnings("unchecked")
E result = (E) elements[--size];
elements[size] = null; // 다 쓴 참조 해제
return result;
}
두 방법 모두 나름의 지지를 얻고 있지만, 현업 에서는 첫 번째 방법을 더 선호한다.
1. 가독성이 더 좋다.
2. 배열의 타입을 E[]로 선언하여 오직 E타입 인스턴스만 받음을 확실히 어필한다.
3. 코드가 더 짧다.
4. 첫 번째 방식에서는 형변환을 배열 생성 시 단 한 번만 해주면 되지만, 두 번째 방식에서는 배열에서 원소를 읽을 때마다 해줘야 한다.
첫 번째 방법의 단점도 있다. 힙오염(아이템 32)을 일으킨다.
다음은 명렬줄 인수들을 역순으로 바꿔 대문자로 출력하는 프로그램으로 방금 만든 제네릭 Stack 클래스를 사용하는 모습을 보여준다.
// 제네릭 stack 사용시 명시적 형변환이 없다 (컴파일러에 의해 수행)
publi static void main(String[] args) {
Stack<String> stack = new Stack<>();
for( String arg : args )
stack.push( arg );
while( !stack.isEmpty() )
System.out.println(stack.pop().toUpperCase());
}
· 타입 매개변수로 기본 타입은 사용할 수 없다. 이는 제네릭 타입 시스템의 근본적인 문제이나, 박싱된 기본 타입(아이템 61)을 사용해 우회할 수 있다.
Ex) Stack<int>, Stack<double>을 만들려고 하면 컴파일 오류가 난다.
아이템 30. 이왕이면 제네릭 메서드로 만들라
핵심 정리
· 제네릭 타입과 마찬가지로, 클라이언트에서 입력 매개변수와 반환값을 명시적으로 형변환해야 하는 메서드보다 제네릭 메서드가 더 안전하며 사용하기도 쉽다.
· 타입과 마찬가지로, 메서드도 형변환 없이 사용할 수 있는 편이 좋으며, 많은 경우 그렇게 하려면 제네릭 메서드가 되어야 한다.
- 기존 클라이언트는 그대로 둔 채 새로운 사용자의 삶을 훨씬 편하게 만들어줄 것이다(아이템 26).
예시 - 로 타입을 사용한 메서드
다음은 두 집합의 합집합을 반환하는, 문제가 있는 메서드다.
// 경고를 없애려면 이 메서드를 타입 안전하게 만들어야 한다
public static Set union(Set s1, Set s2) {
Set result = new HashSet(s1); // unchecked 경고 발생
result.addAll(s2); // unchecked 경고 발생
return result;
}
컴파일은 되지만 경고가 두 개 발생한다. 경고를 없애려면 이 메서드를 타입 안전하게 만들어야 한다.
예시1 - 제네릭 메서드
위의 로 타입을 사용한 메서드를 다음과 같이 수정한다.
- 메서드 선언에서의 세 결합(입력 2개, 반환 1개)의 원소 타입을 타입 매개변수로 명시한다.
- 메서드 안에서도 이 타입 매개벼수만 사용하게 수정한다.
- 타입 매개변수 목록은 메서드의 제한자와 반환 타입 사이에 온다.
다음 코드에서 타입 매개변수 목록은 <E>이고, 반환 타입은 Set<E>이다. 타입 매개변수의 명명 규칙은 제네릭 메서드, 제네릭 타입이 똑같다.
public static <E> Set<E> union(Set<E> s1, Set<E> s2) {
Set<E> result = new HashSet(s1);
result.addAll(s2);
return result;
}
· 위의 제네릭 메서드는 경고 없이 컴파일 되며, 타입 안전하고, 쓰기도 쉽다.
다음은 이 메서드를 사용하는 간단한 프로그램이다. 직접 형변환하지 않아도 오류나 경고 없이 컴파일된다.
public static void main(String[] args) {
Set<String> guys = Set.of("톰", "딕", "해리");
Set<String> stooges = Set.of("래리", "모에", "컬리");
Set<String> aflCio = union( guys, stooges ); // 추정에 의한 사용방법(2)
System.out.println(aflCio);
}
· union 메서드의 문제점: 집합 3개(입력 2개, 반환 1개)의 타입이 모두 같아 한다.
이를 한정적 와일드카드 타입(아이템 31)을 사용하여 더 유연하게 개선할 수 있다.
제네릭 싱글턴 팩터리 패턴
· 불변 객체를 여러 타입으로 활용할 수 있게 만들어야 할 때가 있다. 제네릭은 런타임에 타입 정보가 소거(아이템 28)되므로 하나의 객체를 어떤 타입으로든 매개변수화할 수 있다. 하지만 이렇게 하려면 요청한 타입 매개변수에 맞게 매번 그 객체의 타입을 바꿔주는 정적 팩터리를 만들어야 한다. 이 패턴을 제네릭 싱글턴 팩터리라고 한다.
ex) Collections.reverseOrder 같은 함수 객체(아이템42), Collections.emptySet 같은 컬렉션용으로 사용한다.
· 항등 함수(identity function)을 담은 클래스를 만들고 싶다면, 제네릭 싱글턴 하나면 충분하다.
- 제네릭이 실체화된다면 항등합수를 타입별로 하나씩 만들어야 했을 것이다.
- 물론 자바 라이브러리의 Function.identity를 사용해 항등함수를 담은 클래스를 만들 수 있다.
아래 코드에서 IDENTITY_FN을 UnaryOperator<T>로 형변환하면 비검사 형변환 경고가 발생한다. 하지만 항등함수란 입력 값을 수정 없이 그대로 반환하는 함수이므로, T가 어떤 타입이든 UnaryOperator<T>를 사용해도 타입 안전하다.
따라서 @SuppressWarnings 애너테이션을 추가하자.
// 제네릭 싱글턴 패턴
private static UnaryOperator<Object> ITENTIFY_FN = (t) -> t;
@SuppressWarnings("unchecked")
public static <T> UnaryOperator<T> identifyFunction() {
return (UnaryOperator<T>) IDENTIFY_FN;
}
다음은 제네릭 싱글턴을 사용하는 코드다. 형변환을 하지 않아도 컴파일 오류나 경고가 발생하지 않는다.
public static void main(String[] args) {
String[] strings = { "하나", "둘", "셋" };
UnaryOperator<String> sameString = identifyFunction();
for( String s : strings )
System.out.println( sameString.apply(s) );
Number[] numbers = { 1, 2.0, 3L };
UnaryOperator<Number> sameNumber = identifyFunction();
for( Number n : numbers )
System.out.println( sameNumber.apply(n) );
}
재귀 타입 한정
· 드물게 자기 자신이 들어간 표현식을 사용하여 타입 매개변수의 허용 범위를 한정하는 재귀적 타입 한정(recursive type bound)이 사용된다.
- 재귀적 타입 한정은 주로 타입의 자연적 순서를 정하는 Comparable 인터페이스와 함께 쓰인다.
public interface Comparable<T> {
int compareTo(T o);
}
위 코드에서 타입 매개변수 T는 Comparable<T>를 구현한 타입이 비교할 수 있는 원소의 타입을 정의한다.
- 실제로 거의 모든 타입은 자신과 같은 타입의 원소와만 비교할 수 있다.
ex) String은 Comparable<String>을 구현하고, Integer는 Comparable<Integer>를 구현한다.
Comparable을 구현한 원소의 컬렉션을 입력받는 메서드들을 주로 그 원소들을 정렬 혹은 검색하거나, 최솟값이나 최댓값을 구하는 식으로 사용된다. 이 기능을 수행하려면 컬렉션에 담긴 원소가 상호 비교될 수 있어야 한다.
다음은 이 제약을 코드로 표현한 모습이다. 타입 한정인 <E extends Comparable<E>>는 "모든 타입 E는 자신과 비교할 수 있다"라고 읽을 수 있다.
// 재귀적 타입 한정을 이용해 상호 비교할 수 있음을 표현
public static <E extends Comparable<E>> E max(Collection<E> c);
다음은 방금 선언한 max 메서드의 구현이다. 컬렉션에 담긴 원소의 자연적 순서를 기준으로 최댓값을 계산하며, 컴파일 오류나 경고는 발생하지 않는다.
public static <E extends Comparable<E>> E max(Collection<E> c) {
if( c.isEmpty() )
throw new IllegalArgumentException("컬렉션이 비어 있습니다");
E result = null;
for( E e : c )
if( result == null || e.compareTo(result) > 0 )
result = Objects.requireNonNull(e);
return result;
}
· 이번 아이템에서 설명한 관용구, 와일드카드를 이용한 변형(아이템 31), 시뮬레이트한 셀프 타입 관용구(아이템 2)를 이해하고 나면 실전에서 마주치는 대부분의 재귀적 타입 한정을 무리 없이 다룰 수 있을 것이다.
아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라
핵심 정리
· 조급 복잡하더라도 와일드카드 타입을 적용하면 API가 훨씬 유연해진다.
· 널리 쓰일 라이브러리를 작성한다면 반드시 와일드카드 타입을 적절히 사용하자.
· PECS 공식을 기억하자.
- 생산자(producer)는 extends를 소비자(consumer)는 super를 사용한다.
- Comparable과 Comparator는 모두 소비자라는 사실을 잊지 말자.
매개변수화 타입의 한계
아이템 28에서 매개변수화 타입은 불공변이라고 말했다. 하지만 불공변 방식보다 유연한 무언가가 필요할 때가 있다.
다음은 아이템 29의 Stack 클래스의 public API다.
java public class Stack {
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);
}
위 메서드는 컴파일되지만 완벽하진 않다. Iterable src의 원소 타입이 스택의 원소 타입과 일치하면 잘 작동하지만, Stack<Number>로 선언한 후 pushAll(intVal)을 호출해보자(intVal은 Integer 타입이다.).
Integer는 Number의 하위 타입이니 잘 동작할 것 같지만, 실제로는 오류가 발생한다. 매개변수화 타입이 불공변이기 때문이다.
Stack<Number> numberStack = new Stack<>();
Iterable<Integer> integers = ...;
numberStack.pushAll(integers);
· 자바에서는 이런 상황에 대처할 수 있는 한정적 와일드카드 타입이라는 특별한 매개변수화 타입을 지원한다.
- 아래 코드의 Iterable<? extends E>는 'E의 하위 타입의 Iterable'이어야 한다는 뜻이다.
public void pushAll(Iterable<? extends E> src) {
for( E e : src )
push(e);
}
이제 pushAll과 짝을 이루는 popAll 메서드를 작성하자. popAll 메서드는 Stack 안의 모든 원소를 주어진 컬렉션으로 옮겨 담는다.
// 와일드카드 타입을 사용하지 않은 popAll 메서드 - 결함이 있다.
public void popAll(Collection<E> dst) {
while( !isEmpty() )
dst.add( pop() );
}
위 코드도 컬렉션의 원소 타입이 스택의 원소 타입과 일치한다면 말끔히 컴파일되고, 문제없이 동작하지만, 완벽하진 않다.
Stack<Number>의 원소를 Object용 컬렉션으로 옮기려 한다면, "Collection<Object>는 Collection<Number>의 하위 타입이 아니다"라는 오류가 발생한다.
Stack<Number> numberStack = new Stack<>();
Collection<Object> objects = ...;
numberStack.popAll( objects );
아래 코드는 이를 개선한 코드다. 여기서 와일드카드 타입을 사용한 Collection<? super E>는 'E의 상위 타입의 Collection'이어야 한다는 의미다.
public void popAll(Collection<? super E> dst) {
while( !isEmpty() )
dst.add( pop() );
}
· 이처럼 유연성을 극대화하려면 원소의 생산자나 소비자용 입력 매개변수에 와일드카드 타입을 사용해야한다.
- 와일드카드 타입을 사용하는 기복 원칙인 펙스(PECS) 공식을 기억하자. Poducer-Extends, Consumer-Super
- 즉, 매개변수화 타입 T가 생산자라면 <? extends T>, 소비자라면 <? super T>를 사용하자.
- 받아들여야 할 매개변수를 받고, 거절해야 할 매개변수는 거절하는 작업이 알아서 이뤄진다.
- 클래스 사용자가 와일드카드 타입을 신경 써야 한다면 그 API에 문제가 있을 가능성이 크다.
이전 아이템의 코드 개선
아이템 28에서 Chooser 생산자를 다음과 같이 선언했다.
public Chooser( Collection<T> choices );
이 생성자로 넘겨진 choices 컬렉션은 T 타입의 값을 생산하기만 한다. PECS 공식에 따라 T를 확장하는 와일드카드 타입을 사용해 선언해야 한다.
public Chooser( Collection<? extends T> choices );
이렇게 수정하면, Chooser<Number>의 생성자에 List<Integer>를 넘길 수 있다.
- 수정 전 생성자로는 컴파일조차 되지 않는다.
다음으로 아이템 30의 union 메서드를 살펴보자.
public static <E> Set<E> union( Set<E> s1, Set<E> s2 );
s1과 s2 모두 E의 생상자이니 PECS 공식에 따라 다음처럼 선언한다.
- 반환 타입은 여전히 Set<E>임에 주목하자. 반환 타입에는 한정적 와일드카드 타입을 사용하면 안 된다. 유연성을 높여주기는커녕 클라이언트 코드에서도 와일드카드 타입을써야 하기 때문이다.
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);
앞의 코드는 자바 8부터 제대로 컴파일된다. 자바 7까지는 타입 추론 능력이 부족하여 문맥에 맞는 반환 타입(혹은 목표 타입)을 명시해야한다.
Set<Number> numbers = union(integers, doubles); // imcompatible types 오류 발생
이 오류는 컴파일러가 올바른 타입을 추론하지 못할 때 명시적 타입 인수를 사용해서 타입을 알려주는 방법으로 해결 할 수 있다.
- 목표 타이핑(target typing)은 자바 8부터 지원하기 시작했다.
// 자바 7 이하에서도 깨끗이 컴파일 된다.
Set<Number> numbers = Union.<Number>union(integers, doubles);
다음으로 아이템 30의 max 메서드를 살펴보자.
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>로 수정했다.
타입 매개변수에서 Comparable<E>는 E 인스턴스를 소비하므로, Comparable<? super E>로 대체했다.
- Comparable과 Comparator는 언제나 소비자이므로 Comparable<? super E> 형태로 사용하자.
타입 매개변수와 와일드카드 둘 다 가능한 메서드 정의
· 타입 매개변수와 와일드카드에는 공통되는 부분이 있어서, 메서드를 정의할 때 둥 중 어느 것을 사용해도 괜찮을 때가 많다.
다음은 그 예시다. 주어진 리스트에서 명시한 두 인덱스의 아이템들을 교환(swap)하는 정적 메서드다.
// swap 메서드의 두 가지 선언
public static <E> void swap(List<E> list, int i, int j);
public static void swap(List<?> list, int i, int j);
어떤 선언이 더 낫고, 더 나은 이유는 무엇일까?
public API라면 간단한 두 번째가 더 낫다.
어떤 리스트든 이 메서드에 넘기면 명시한 인덱스의 원소들을 교환해 줄 것이고, 신경 써야 할 매개변수도 없다.
· 기본 규칙: 메서드 선언에 타입 매개변수가 한 번만 나오면 와일드 카드로 대체하라.
- 비한정적 타입 매개변수라면 비한정적 와일드 카드로 바꾸고, 한정적 타입 매개변수라면 한정적 와일드카드로 바꾼다.
두 번째 swap 선언에는 문제가 하나 있다. 다음과 같이 아주 직관적으로 구현한 코드가 컴파일되지 않는다는 것이다.
public static void swap(List<?> list, int i, int j) {
list.set(i, list.set(j, list.get(i)));
}
이 코드를 컴파일 하면 다음과 같은 오류가 발생한다. 즉, 방금 꺼낸 원소를 리스트에 다시 넣을 수 없다.
원인은 리스트의 타입이 List<?>인데, List<?>에는 null 외에는 어떤 값도 넣을 수 없다는 데 있다.
이 문제는 실제 타입을 알려주는 메서드를 private 도우미 메서드로 따로 작성하여 활용하는 방식으로 해결할 수 있다.
- 실제 타입을 알아내려면 이 도우미 메서드는 제네릭 메서드여야 한다.
public static void swap(List<?> list, int i, int j) {
swapHelper(list, i, j);
}
// 와일드카드 타입을 실제 타입으로 바꿔주는 private 도우미 메서드
private static <E> void swapHelper(List<E> list, int i, int j) {
list.set(i, list.set(j, list.get(i)));
}
· 결과적으로 swap 메서드 내부에서는 더 복잡한 제네릭 메서드를 이용했지만, 덕분에 외부에서는 와일드카드 기반의 멋진 선언을 유지할 수 있었다.
- 즉, swap 메서드를 호출하는 클라이언트는 복잡한 swapHelper의 존재를 모든 채 그 혜택을 누린다.
아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라
핵심 정리
· 가변인수와 제네릭은 궁합이 좋지 않다.
- 가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하고, 배열과 제네릭의 타입 규칙이 서로 다르기 때문이다.
· 제네릭 varargs 매개변수를 사용하고자 한다면, 먼저 그 메서드가 타입 안전한지 확인한 다음 @SafeVarargs 애너테이션을 달아 사용하는 데 불편함이 없게끔 하자.
제네릭과 가변인수 메서드
· 가변인수(varargs) 메서드(아이템 53)와 제네릭은 자바 5 때 함께 추가되었지만, 잘 아울어지지 못했다.
· 가변인수는 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해주는데, 구현 방식에 허점이있다.
- 가변인수 메서드를 호출하면 가변인수를 담기 위해 배열이 자동으로 하나 만들어지는데, 이 배열이 내부로 감춰지지 않고 클라이언트에 노출된다. 그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생한다.
예시 - 제네릭과 가변인수를 함께 사용
· 매개변수화 타입의 타입이 다른 객체를 참조하면 힙 오염이 발생한다.
- 이렇게 다른 타입 객체를 참조하는 상황에는 컴파일러가 자동 생성한 형변환이 실패할 수 있으니, 제네릭 타입 시스템이 약속한 타입 안전성의 근간이 흔들린다.
// 제네릭과 varargs를 혼용하면 타입 안전성이 깨진다.
static void dangerous(List<String>... stringLists) {
List<Integer> intList = List.of(42);
Object[] objects = stringLists;
objects[0] = intList; // 힙 오염 발생
String s = stringLists[0].get(0); // ClassCastException
}
위 메서드는 형변환하는 곳이 보이지 않는데도 인수를 건데 호출하면 ClassCastException을 던진다. 마지막 줄에 컴파일러가 생성한 (보이지 않는) 형변환이 숨어 있기 때문이다.
· 이처럼 타입 안전성이 깨지니 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.
제네릭 varargs 매개변수를 받는 메서드를 선언할 수 있게 한 이유는?
· 제네릭 배열은 프로그래머가 직접 작성하는 건 허용되지 않지만, 제네릭 varargs 매개변수를 받는 메서드는 선언할 수 있다. (경고만 발생하고, 컴파일을 된다)
· 제네릭이나 매개변수화 타입의 varargs 배열을 받는 메서드가 실무에서 매우 유용하기 때문이다.
- 그래서 언어 설계자는 이 모순을 수용하기로 했다.
· 자바 라이브러리에서는 이런 메서드를 여럿 제공한다. 다행이 이들은 타입 안전하다.
ex) Arrays.asList<T... a), Collections.addAll(Collection<? super T> c, T... elements)
· 자바 7 전에는 제네릭 가변인수 메서드의 작성자가 호출자 쪽에서 발생하는 경고에 대해 해줄 수 있는 일이 없었다. 따라서 이런 메서드는 사용하기에 좀 꺼림칙했다.
- 사용자는 이 경고들을 그냥 두거나, 호출하는 곳 마다 @SuppressWarnings("unchecked") 애너테이션을 달아 경고를 숨겨야 했다.
- 이는 지루한 작업이고, 가독성을 떨어뜨리고, 진짜 문제를 알려주는 경고마저 숨기는 안 좋은 결과로 이어졌다.
· 자바 7부터 @SafeVarargs 애너테이션이 추가되어 제네릭 가변인수 메서드 작성자가 클라이언트 측에서 발생하는 경고를 숨길 수 있다.
- @SafeVarargs 애너테이션은 메서드 작성자가 그 메서드의 타입 안전함을 보장하는 장치다. 컴파일러는 이 약속을 믿고 그 메서드가 안전하지 않을 수 있다는 경고를 더 이상 하지 않는다.
· @SafeVarargs 애너테이션은 재정의할 수 없는 메서드에만 달아야 한다.
- 재정의한 메서드도 안전할지는 보장할 수 없기 때문이다.
- 자바 8에서 이 애너테이션은 오직 정적 메서드와 final 인스턴스 메서드에만 붙일 수 있다.
- 자바 9부터는 private 인스턴스 메서드에도 허용된다.
메서드가 안전한지 어떻게 확신할 수 있을까?
· 가변 인수 메서드를 호출할 때 varargs 매개변수를 담는 제네릭 배열이 만들어진다. 메서드가 이 배열에 아무것도 저장하지 않고(그 매개변수들을 덮어쓰지 않고), 그 배열의 참조가 밖으로 노출되지 않는다면 타입 안전하다.
- 즉, varargs 매개변수 배열이 호출자로부터 그 메서드로 순수하게 인수들을 전달하는 일만 한다면, 그 메서드는 안전하다.
타입 안정성을 깨는 사례
· varargs 매개변수 배열에 아무것도 저장하지 않고도 타입 안전성을 깰수도 있으니 주의해야 한다.
다음은 가변인수로 넘어온 매개변수들을 배열에 담아 반환하는 제네릭 메서드다.
// 자신의 제네릭 매개변수 배열의 참조를 노출한다. - 안전하지 않다.
static <T> T[] toArray(T... args) {
return args;
}
이 메서드가 반환하는 배열의 타입은 이 메서드의 인수를 넘기는 컴파일타임에 결정되는데, 그 시점에는 컴파일러에게 충분한 정보가 주어지지 않아 타입을 잘못 판단할 수 있다. 따라서 자신의 varargs 매배변수 배열을 그대로 반환하면 힙 오염을 이 메서드를 호출한 쪽의 콜스택까지 전이하는 결과를 낳을 수 있다.
다음 메서드는 T 타임 인수 3개를 받아 그중 2개를 무작위로 골라 담은 배열을 반환한다.
static <T> T[] pickTwo(T a, T b, T c) {
switch( ThreadLocalRandom.current().nextInt(3)) {
case 0: return toArray(a, b);
case 1: return toArray(a, c);
case 2: return toArray(b, c);
}
throw new AssertionError(); // 도달할 수 없다
}
이 메서드를 본 컴파일러는 toArray에 넘길 T 인스턴스 2개를 담을 varargs 매개변수 배열을 만드는 코드를 생성한다. 이 코드가 만드는 배열의 타입은 Object[]이다. pickTwo에 어떤 타입의 객체를 넘기더라도 담을 수 있는 가장 구체적인 타입이기 때문이다.
그리고 toArray 메서드가 돌려준 이 배열(Object[] 타입)이 그대로 pickTwo를 호출한 클라이언트까지 전달된다.
이제 pickTwo를 사용하는 main 메서드를 보자.
public static void main(String[] args) {
String[] attributes = pickTwo("좋은", "빠른", "저렴한");
}
별다른 경고 없이 컴파일되지만, 실행하면 ClassCastException을 던진다.
pickTwo의 반환값을 attributes에 저장하기 위해 String[]로 형변환하는 코드를 컴파일러가 자동 생성하기 때문이다. Object[]는 String[]의 하위 타입이 아니므로 이 형변환은 실패한다.
힙 오염을 발생시킨 원인은 toArray로부터 두 단계나 떨어져 있고, varargs 매개변수 배열은 실제 매개변수가 저장된 후 변경된 적도 없다.
· 이 예는 제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다는 점을 상기시킨다.
제네릭 varargs 매개변수를 안전하게 사용하는 예시
· 제네릭 varargs 매개변수 배열에 다른 메서드가 접근해도 안전한 두 가지 경우가 있다.
1. @SafeVarargs로 제대로 애너테이트된 또 다른 varargs 메서드에 넘기는 것은 안전하다.
2. 배열 내용의 일부 함수를 호출만 하는(varargs를 받지 않는) 일반 메서드에 넘기는 것은 안전하다.
다음 코드는 제네릭 varargs 매개변수를 안전하게 사용하는 전형적인 예다.
flatten 메서드는 임의 개수의 리스트를 인수로 받아, 받은 순서대로 그 안의 모든 원소를 하나씩 리스트로 옮겨 담아 반환한다.
이 메서드에서는 @SafeVarargs 애너테이션이 달려 있어 선언하는 쪽과 사용하는 쪽 모두 경고를 내지 않는다.
// 제네릭 varags 매개변수를 안전하게 사용하는 메서드
@SafeVarargs
static <T> List<T> flatten(List<? extends T>... lists) {
List<T> result = new ArrayList<>();
for( List<? extends T> list : lists )
result.addAll(list);
return result;
}
· @SafeVarargs 애너테이션을 사용해야 할 때를 정하는 규칙: 제네릭이나 매개변수화 타입의 varargs 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에 @SafeVarargs를 달라.
- 그래야 사용자를 헷갈리게 하는 컴파일러 경로를 없앨 수 있다.
- 이 말은 안전하지 않은 varargs 메서드는 절대 작성해서는 안 된다는 뜻이다.
· 우리가 통제할 수 있는 메서드 중 제네릭 varargs 매개변수를 사용하며 힙 오염 경고가 뜨는 메서드가 있다면, 그 메서드가 진짜 안전한지 점검하자.
- 다음 두 조건을 모두 만족하는 제네릭 varargs 메서드는 안전하다. 둘 중 하나라도 어겼다면 수정하자.
1. varargs 매개변수 배열에 아무것도 저장하지 않는다.
2. 그 배열(혹은 복제본)을 신뢰할 수 없는 코드에 노출하지 않는다.
· @SafeVarargs 애너테이션을 사용하지 않고, 아이템 28의 조언을 따라 varargs 매개변수를 List 매개변수로 바꿀 수도 있다.
// 제네릭 varargs 매개변수를 List로 대체한 예 - 타입 안전하다.
static <T> List<T> flatten(List<List<? extends T>> lists) {
List<T> result = new ArrayList<>();
for( List<? extends T> list : lists )
result.addAll(list);
return result;
}
정적 팩터리 메서드인 List.of를 활용하면 다음과 같이 이 메서드에 임의 개수의 인수를 넘길 수 있다.
- List.of에도 @SafeVarargs 애너테이션이 달려 있기 때문에 가능하다.
audience = flatten(List.of(friends, romans, countrymen));
· 이 방식의 장점은 컴파일러가 이 메서드의 타입 안전성을 검증할 수 있다는 데 있다.
- @SafeVarargs 애너테이션을 직접 달지 않아도 되고, 실수로 안전하다고 판단할 걱정도 없다.
· 이 방식은 단점은 클라이언트 코드가 살짝 지저분해지고, 속도가 조금 느려질 수 있다는 정도다.
· 이 방식은 위의 toArray 메서드처럼 varargs 메서드를 안전하게 작성하는 게 불가능한 상황에도 쓸 수 있다.
- 이 toArray의 List 버전이 바로 자바 라이브러리에서 제공하는 List.of다.
static <T> List<T> pickTwo(T a, T b, T c) {
switch( ThreadLocalRandom.current().nextInt(3)) {
case 0: return List.of(a, b);
case 1: return List.of(a, c);
case 2: return List.of(b, c);
}
throw new AssertionError();
}public static void main(String[] args) {
List<String> attributes = pickTwo("좋은", "빠른", "저렴한");
}
아이템 33. 타입 안전 이종 컨테이너를 고려하라
핵심 정리
· 컬렉션 API로 대표되는 일반적인 제네릭 형태에서는 한 컨테이너가 다룰 수 있는 타입 매개변수의 수가 고정되어 있다. 하지만 컨테이너 자체가 아닌 키를 타입 매개변수로 바꾸면 이런 제약이 없는 타입 안전 이종 컨테이너를 만들 수 있다.
- 타입 안전 이종 컨테이너는 Class를 키로 쓰며, 이런 식으로 쓰이는 Class 객체를 타입 토큰이라 한다.
- 직접 구현한 키 타입도 쓸 수 있다. 예컨대 데이터베이스의 행(컨테이너)을 표현한 DatabaseRow 타입에는 제네릭 타입인 Column<T>를 키로 사용할 수 있다.
단일 원소 컨테이너
· 제네릭은 Set<E>, Map<K, V> 등 단일원소 컨테이너에 흔히 쓰인다.
· 하나의 컨테이너에서 매개변수화할 수 있는 타입의 수는 제한된다.
- 원인: 매개변수화되는 대상은 원소가 아닌 컨테이너 자신이기 때문이다.
- 컨테이너의 일반적인 용도에 맞게 설계된 것이니 문제될 건 없다. Set에는 원소 타입을 뜻하는 단 하나의 타입 매개변수만 있으면 되고, Map에는 키와 값이 타입을 뜻하는 2개만 필요한 식이다.
타입 안전 이종 컨테이너
· 위에서 말한 사례보다 더 유연한 수단이 필요할 때가 종종 있다.
ex) 데이터베이스의 행은 임의 개수의 열을 가질 수 있는데, 모두 열을 타입 안전하게 이용할 수 있다면 멋질 것이다.
· 컨테이너 대신 키를 매개변수화한 다음, 컨테이너에 값을 넣거나 뺄 때 매개변수화한 키를 함께 제공하는 식으로 위 문제를 해결 할 수 있다. 이렇게 하면 제네릭 타입 시스템이 값의 타입이 키와 같음을 보장해 준다.
- 이러한 설계 방식을 타입 안전 이종 컨테이터 패턴(type safe heterogeneous container pattern)이라고 한다.
예시 - 타입 안전 이종 컨테이너를 사용하는 Favorites 클래스
타입별로 즐겨 찾는 인스턴스를 저장하고, 검색할 수 있는 Favorites 클래스를 생각해보자.
· 각 타입의 Class 객체를 매개변수화한 키 역할로 사용하면 되는데, 이 방식이 동작하는 이유는 class의 클래스가 제네릭이기 때문이다.
- class 리터럴 타입은 Class가 아닌 Class<T>다.
ex) String.class 타입은 Class<String>이고 Integer.class의 타입은 Class<Integer>이다.
- 컴파일타임 타입 정보와 런타임 타입 정보를 알아내기 위해 메서드들이 주고 받는 class 리터럴을 타입 토큰(type token)이라 한다.
public class Favorites {
public <T> void putFavorites(Class<T> type, T instance);
public <T> T getFavorites(Class<T> type);
}
위 코드는 Favorites 클래스의 API로, 키가 매개변수화되었다는 점만 빼면 일반 맵처럼 보일다.
클라이언트는 즐겨찾기를 저장하거나 얻어올 때 Class 객체를 알려주면 된다.
다음은 Favorites 클래를 사용하는 예시다. 즐겨 찾는 String, Integer, Class 인스턴스를 저장, 검색, 출력하고 있다.
이 프로그램은 기대한 대로 Java cafebabe Favorites를 출력한다.
public static void main(String[] args) {
Favorites f = new Favorites();
f.putFavorites(String.class, "Java");
f.putFavorites(Integer.class, 0xcafebabe);
f.putFavorites(Class.class, Favorites.class);
String favoriteString = f.getFavorites(String.class);
int favoriateInteger = f.getFavorites(Integer.class);
Class<?> favoriateClass = f.getFavorites(Class.class);
System.out.printf("%s %x %s%n", favoriteString,
favoriateInteger, favoriateClass.getName());
}
· Favorites 인스턴스의 장점:
1. 타입 안전하다.
- String을 요청했는데, Integer를 반환하는 일은 없다.
2. 모든 키의 타입이 제각각이라, 일반적인 맵과 달리 여러 가지 타입의 원소를 담을 수 있다.
- Favorites는 타입 안전 이종(heterogeneous) 컨테이너라 할 만하다.
// 타입 안전 이종 컨테이너 패턴 - 구현
public class Favorites {
private Map<Class<?>, Object> favorites = new HashMap<>();
public <T> void putFavorites(Class<T> type, T instance) {
favorites.put(Objects.requireNonNull(type), instance);
}
public <T> T getFavorites(Class<T> type) {
return type.cast(favorites.get(type));
}
}
· favorites의 타입은 Map<Class<?>, Object>이다.
비한정적 와일드카드 타입이라 이 맵 안에 아무것도 넣을 수 없다고 생각할 수 있지만, 사실은 그 반대다. 와일드카드 타입이 중첩(nested)되었다는 점을 깨달아야 한다. 맵이 아니라 키가 와일드카드 타입인 것이다. 이는 모든 키가 서로 다른 매개변수화 타입일 수 있다는 뜻이다.
- 다양한 타입을 지원하는 힘이 여기서 나온다.
ex) Class<String>, Class<Integer>
· favorites 맵의 값 타입은 단순히 Object다.
이 맵은 키와 값 사이의 타입 관계를 보증하지 않는다는 말이다. 즉, 모든 값이 키로 명시한 타입임을 보증하지 않는다. 자바의 타입 시스템에서는 이 관계를 명시할 방법이 없다. 하지만 우리는 이 관계가 성립함을 알고 있고, 즐겨찾기를 검색할 때 그 이점을 누리게 된다.
· putFavorites는 주어진 Class 객체와 즐겨찾기 인스턴스를 favorites에 추가해 관계를 맺는다.
· getFavorites 코드는 주어진 Class 객체에 해당하는 값을 favorites 맵에서 꺼낸다.
이 객체가 바로 반환해야 할 객체가 맞지만, 잘못된 컴파일타임 타입을 가지고 있다. 이 객체의 타입은 favorites 맵의 값 타입인 Object이다. 우리는 이를 T로 바꿔 반환해야 한다.
- 즉, getFavorite 구현은 Class cast 메서드를 사용해 이 객체 참조를 Class 객체가 가리키는 타입으로 동적 형변환한다.
- cast 메서드는 형변환 연산자의 동적 버전이다. 주어진 인수가 Class 객체가 알려주는 타입 인스턴스인지 검사하여 맞다면 그 인수를 그대로 반환하고, 아니면 ClassCastException을 던진다.
· cast 메서드가 인수를 그대로 반환하기만 하는데, 굳이 사용하는 이유는 해당 메서드의 시그니처가 Class 클래스가 제네릭이라는 이점을 완벽히 활용하기 때문이다.
cast의 반환 타입은 Class 객체의 타입 매개변수와 같다.
public class Class<T> {
T cast(Object obj);
}
이것은 getFavorite 메서드에 필요한 기능으로, T로 비검사 형변환하는 손실 없이도 Favorites를 타입 안전하게 만드는 비결이다.
· Favorites 클래스의 제약:
1. 악의적인 클라이언트가 Class 객체를 로 타입(아이템 26)으로 넘기면 Favorites 인스턴스의 타입 안전성이 쉽게 깨진다.
- 하지만 클라이언트 코드에서 컴파일할 때 비검사 경고가 뜰 것이다.
Favorites가 타입 불변식을 어기는 일이 없도록 보장하려면 putFavorites 메서드에서 인수로 주어진 instance의 타입이 type으로 명시한 타입과 같은지 확인하면 된다. 다음과 같이 동적 형변환을 사용한다.
public <T> void putFavorites(Class<T> type, T instance) {
favorites.put(Objects.requireNonNull(type), type.cast(instance));
}
java.util.collection에는 checkedSet, checkedList, checkedMap 같은 메서드가 있는데, 바로 이 방식을 적용한 컬렉션 래퍼들이다.
이 정적 팩터리들은 컬렉션(혹은 맵)과 함께 1개(혹은 2개)의 Class 객체를 받는다.
이 메서드들은 모두 제네릭이라 Class 객체와 컬렉션의 컴파일타임 타입이 같음을 보장한다. 또한 이 래퍼들은 내부 컬렉션들을 실체화한다. 이 래퍼들은 제네릭과 로 타입을 섞어 사용하는 애플리케이션에서 클라이언트 코드가 컬렉션에 잘못된 타입의 원소를 넣지 못하게 추적하는 데 도움을 준다.
ex) 런타임에 Coin을 Collection<Stamp>에 넣으려 하면 ClassCastException을 던진다.
2. 실체화 불가 타입(아이템 28)에는 사용할 수 없다.
- 즉, String이나 String[]은 저장할 수 있어도 List<String>은 저장할 수 없다. 저장하려하면 코드는 컴파일되지 않는다. List<String>용 Class를 얻을 수 없기 때문이다.
- 해당 제약에 대한 만족스러운 우회로는 없다.
- (옮기이) 해당 제약을 슈퍼 타입 토큰으로 해결하려는 시도도 있다. 하지만, 이 방법도 완벽하지 않으므로 주의해서 사용하자.
TODO: 슈퍼 타입 토큰(super type token)
· Favorites가 사용하는 타입 토큰은 비한정적이다.
- 즉, getFavorite와 putFavorite는 어떤 Class 객체든 받아들인다.
- 이 메서드들이 허용하는 타입을 제한하고 싶다면 한정 타입 토큰을 사용하자.
- 한정 타입 토큰: 한정적 타입 매개변수(아이템 29)나 한정적 와일드카드(아이템 31)를 사용하여 표현 가능한 타입을 제한하는 타입 토큰
· 애너테이션 API(아이템 39)는 한정적 타입 토큰을 적극적으로 사용한다.
다음 코드는 AnnotatedElement 인터페이스에 선언된 메서드로 대상 요소에 달려 있는 애너테이션을 런타입에 읽어온다.
publc <T extends Annotation>
T getAnnoTation(Class<T> annotationType);
이 메서드는 리플렉션의 대상이 되는 타입들(java.lang.Class<T>, java.lang.reflect.Method, java.lang,reflect.Field)을 프로그램 요소를 표현하는 타입들에서 구현한다.
annotationType 인수는 애너테이션 타입을 뜻하는 한정적 타입 토큰이다. 이 메서드는 토큰으로 명시한 타입의 애너테이션이 대상 요소에 달려 있다면 그 애너테이션을 반환하고, 없다면 null을 반환한다.
- 즉, 애너테이션된 요소는 그 키가 애너테이션 타입인 타입 이종 컨테이너다.
Class<?> 타입의 객체를 한정적 타입 토큰을 받는 메서드(getAnnotation)에 넘겨야 한다면?
객체를 Class<? extends Annotaion>으로 형변환할 수도 있지만, 이 형변환은 비검사이므로 컴파일하면 경고가 뜬다(아이템 27).
Class 클래스는 이런 형변환을 안전하고, 동적으로 수행해주는 asSubClass 인스턴스를 제공한다. 이는 호출된 인스턴스 자신의 Class 객체를 인수가 명시한 클래스로 형변환한다.
- 형변환된다는 것은 이 클래스가 인수로 명시한 클래스의 하위 클래스라는 뜻이다.
형변환에 성공하면 인수로 받은 클래스 객체를 반환하고, 실패하면 ClassCastException을 던진다.
다음은 컴파일 시점에는 타입을 알 수 없는 애너테이션을 asSubclass 메서드를 런타임에 읽어내는 예다. 이 메서드는 오류나 경고 없이 컴파일 된다.
static Annotation getAnnotation(AnnotatedElement element, String annotationTypeName) {
Class<?> annotationType = null; // 비한정적 타입 토큰
try{
annotationType = Class.forName(annotationTypeName);
} catch( Exception ex){
throw new IllegalArgumentException(ex);
}
// asSubclass 가 실패하면 ClassCastException 을 던진다
return element.getAnnotation( annotationType.asSubclass(Annotation.class));
}
옮긴이의 말
· 매개변수(parameter)는 메서드에 선언한 변수이고, 인수(argument)는 메서드 호출 시 넘기는 '실젯값'이다.
아래 코드에서 value는 매개변수이고 10은 인수다.
void add(int value) {...}
add(10)
이 정의를 제네릭까지 확장할 수 있다. 아래 코드에서 T는 타입 매개변수가 되고, Integer는 타입 인수가 된다.
자바 언어 명세에서는 이를 구분하고 있다.
class Set<T> { ... }
Set<Integer> = ...;
출처
이펙티브 자바 3판
'자바 > 이펙티브자바' 카테고리의 다른 글
| [Effective Java] 이펙티브자바 정리: 7장 람다와 스트림 (0) | 2022.02.07 |
|---|---|
| [Effective Java] 이펙티브자바 정리: 4장 클래스와 인터페이스 (0) | 2022.01.27 |
| [Effective Java] 이펙티브자바 정리: 3장 모든 객체의 공통 메서드 (0) | 2022.01.25 |
| [Effective Java] 이펙티브자바 정리: 2장 객체 생성과 파괴 (0) | 2022.01.24 |
댓글