[이펙티브 자바] 5장 : 제네릭

제네릭 지원하기 전 자바자는 컬렉션에서 객체를 꺼낼 때마다 형변환을 해야했음 (이는 실수로 인한 런타임에러를 발생시킴)

그래서 컴파일러는 알아서 형변환 코드를 추가할 수 있고 엉뚱한 타입의 객체를 넣으려는 시도를 컴파일 과정에서 차단하여 더 안전하고 명확한 프로그램을 만들어준다.

제네릭의 이점을 최대한 살리고 단점을 최소화하여 사용해보자.

아이템 26 : 로(raw) 타입은 사용하지 마라

클래스, 인터페이스 선언에 ‘타입 매개변수'가 쓰이면 제네릭 클래스, 인터페이스라고 부름

→ 이를 통틀어 ‘제너릭 타입'이라고 함

→ ‘제네릭 타입’은 매개변수화 타입을 정의한다.

→ ‘제네릭 타입'을 정의하면 ‘raw 타입' 도 정의된다. (타입 매개변수를 사용하지 않는 타입) ex) List<E> → List (제네릭 도래 전 코드와 호환을 위해 존재)

범용적인 코드를 만들기 위해 여러 타입을 허용하고 사용할 때 캐스팅하는 방법은 컴파일 타임에는 오류가 나지 않기 때문에 좋은 방법이 아니다.

• 런타임에서야 오류가 발생
• 오류 원인의 위치와 런타임 시 오류 발생 위치가 멀리 떨어져 있다. (전체 코드에서 오류를 찾아야할 수도 있다)

오류는 가능한 한 컴파일할 때 발견하는 것이 가장 좋다!

제네릭을 활용하면 타입 정보가 선언 자체에 녹아들게 된다.

private final Collections<Stamp> stamps = ...;

위처럼 타입 정보를 명시하면 Stamp의 인스턴스만 넣어야 컴파일러가 인지하게 된다. 아니라면 컴파일 오류발생. (컴파일러가 컬렉션에서 원소를 꺼내는 모든 곳에서 보이지 않는 명시된 타입으로의 형변환을 추가한다)

raw의 타입을 쓰면 안된다

제네릭이 주는 안정성과 표현력을 모두 잃게 된다. 로 타입은 단지 호환성 때문에 만들어 둔 것이다. (지금까지 쌓이 로타입코드들을 위한...)

<?> 비한정적 와일드카드

실제 타입 매개변수가 신경쓰지 않고 제네릭 사용 싶을 때

예외

클래스 리터럴은 로타입을 써야한다. 매개변수화 타입 금지

ex) List.class, String[].class, List<?>.classe

로 타입을 사용하면 런타임에 예외가 발생할 수 있고 제네릭 타입시스템이 아니고 안전하지 않다.

아이템 27 : 비검사 경고를 제거하라

비검사 경고는 런타임에 예외를 발생시킬 수 있는 가능성을 말한다.

이 예외가 발생하지 않도록 최대한 제거하고 제거 시킬 방법이 없다면 @SuppressWarning("unchecked") 를 통해 경고를 숨긴다.

이후 경고를 무시해도 되는 이유를 주석을 남겨야 한다.

아이템 28 : 배열보다는 리스트를 사용하라

• 배열은 공변이다. (하위타입[]이 상위 타입[] 가능)
  • 런타임에 실패

// 런타임에 실패
Obejct[] objectArray = new Long[1];
objectArray[0] = "타입이 다르다"; // ArrayStoreException

• List<하위타입>과 List<상위타입> 서로 하위/상위 타입이 아님 (제네릭)
  • 컴파일 타임에 실패

// 컴파일타임에 실패
List<Object> ol = new ArrayList<Long>(); // 호환되지 않는 타입. 컴파일 에러
ol.add("타입이 다르다");

제네릭을 배열에 사용하려면 비검사 형변환을 제거해야할 수 도 있고 형변환 예외도 겪을 수 있다.

배열보다는 리스트를 사용하면 오류나 경고없이 컴파일 할 수 있다.

아이템 29 : 이왕이면 제네릭 타입으로 만들라

제네릭 타입을 만드는 것은 조금 복잡하다.

하지만 클라이언트에서 직접 형변환하는 것보다 제네릭 타입이 더 안전하고 쓰기 편하다. (직접 형변환 필요 없어짐)

제네릭을 사용하면 기존 클라이언트에 영향을 주지 않으면서 사용할 수 있다.

아이템 30 : 이왕이면 제네릭 메서드로 만들라

제네릭 메서드를 사용하면 경고없이 컴파일되며, 타입 안전하고, 쓰기 쉽다.

직접 형변환하지 않아도 컴파일 된다.

public static <E> Set<E> union(Set<E> s1, Set<E> s2) {
  	Set<E> result = new HashSet<>(s1);
  	result.addAll(s2);
  	return result;
}

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

‘매개변수화 타입’은 불공변이다. 즉, List<하위타입>과 List<상위타입>는 서로 하위/상위 타입이 아니다.

한정적 와일드카드를 사용하지 않고 그냥 매개변수화 타입을 사용하면 서로 불공변이기 때문에 맞지않는 타입이라고 에러가 발생한다.

하지만 아래 코드처럼 ‘한정적 와일드카드'를 사용하면 “E의 하위 또는 상위타입인 것들을 포함한다”여서 유연성이 극대화 된다.

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

public void popAll(Collection<? super E> dst) { // consumer : dst
  	while (!isEmpty())
      	dst.add(pop());
}

아이템 32: 제네릭과 가변인수를 함께 쓸 때는 신중하자

가변인수는 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 하는 기능이다.

가변인수 메서드 호출 → 가변인수를 담는 배열 생성

가변인수는 배열을 내부로 감추지 못하고 노출하기 때문에 추상화가 완벽하지 못하다.

타입 안전하지 않지만 허용된다.

제네릭에 가변인수를 사용한다면 메서드가 타입 안전하지 항상 확인하도록 조심해서 사용하자.

아이템 33 : 타입 안전 이종 컨테이너를 고려하라

일반적인 제네릭 형태에서는 한 컨테이너가 다룰 수 있는 타입 매개변수의 수가 고정되어 있다. ex) Map<K, V>, List<K> 등..

컨테이너 자체가 아닌 키를 ‘타입 매개변수로' 바꾸면 제약없는 ‘타입 안전 이종 컨테이너'를 만들 수 있다.

Class를 키로 쓰며 이를 타입토큰이라 한다.

 

-클라이언트 코드-

// 코드 33-2 타입 안전 이종 컨테이너 패턴 - 클라이언트 (199쪽)
    public static void main(String[] args) {
        Favorites f = new Favorites();
        
        f.putFavorite(String.class, "Java");
        f.putFavorite(Integer.class, 0xcafebabe);
        f.putFavorite(Class.class, Favorites.class);
       
        String favoriteString = f.getFavorite(String.class);
        int favoriteInteger = f.getFavorite(Integer.class);
        Class<?> favoriteClass = f.getFavorite(Class.class);
        
        System.out.printf("%s %x %s%n", favoriteString,
                favoriteInteger, favoriteClass.getName());
    }

-Favorite코드-

public class Favorites {
  	private Map<Class<?>, Object> favorites = new HashMap<>();
  	
  	public <T> void putFavorite(Class<T> type, T instance) {
      	favorites.put(Object.requireNonNull(type), instance);
    }
  
  	public <T> getFavorite(Class<T> type) {
      	return type.cast(favorite.get(type));
    }
}

맵이 아닌 키가 와일드 타입이기 때문에 모든 키가 서로 다른 매개변수화 타입일 수 있다는 뜻이다.

따라서, Class<String>이든 Class<Integer>든 모두 가능하다. (다양한 타입지원)

 

Map의 값 타입은 단순히 Object이다. 이는 키와 값사이의 타입관계를 보증하지 않는다는 것이다.

하지만 우리는 값을 꺼낼 때 키를 넘겨 받아서 그로 캐스팅하여 동적 형변환할 수 있다.