아이템 26. 로 타입은 사용하지 말라

[JoisFe]

아이템 26. 로 타입은 사용하지 말라

해당 아이템의 제목에 ~로 에서 ~를 실수로 생략한 것이 아니라 로는 raw 임을 먼저 이야기 하고 시작 (사실 제가 처음에 뭐지 ?? 뺴먹었나? 라 생각했습니다.)

그래서 왜 raw type은 사용하지 말라는 건지 알기 이전에 Generic에 대한 첫 아이템이다 보니 용어 정리부터!!

용어 정리

타입 매개변수

제네릭 클래스를 정의할때 사용하며 괄호 <와 > 사이에 타입 매개변수를 쉼표로 구분하여 늘어 놓음

public interface IndexInterface<T> { }

여기서 T가 타입 매개변수이다.

제네릭 클래스, 제네릭 인터페이스

클래스와 인터페이스 선언에 타입 매개변수가 쓰이면 이를 제네릭 클래스 혹은 제네릭 인터페이스라 함.

제네릭 타입 (Generic Type)

제네릭 클래스와 제네릭 인터페이스를 통틀어 제네릭 타입이라 함.

로 타입 (Raw Type)

제네릭 타입에서 타입 매개변수를 전혀 사용하지 않을 때

ex) List의 로 타입은 List

왜 로 타입으로 사용하면 안될까?

오류는 가능한 발생 즉시, 이상적으로는 컴파일할 때 발견하는 것이 좋다.

// Stamp 인스턴스만 취급. private final Collection stamps = ...; stamps.add(new Coin(...));

제네릭을 지원하기 전 컬렉션을 위 코드와 같이 선언하였음.
이 코드를 사용하면 실수로 Stamp 대신 Coin을 넣어도 아무 오류없이 컴파일되고 실행됨 (컴파일러가 모호한 경고 메시지를 보여줄 수도 있음)

이 후 컬렉션에서 이 동전을 다시 꺼내기 전에는 오류를 알 수가 없음.

for (Iterator i = stamps.iterator(); i.hasNext();) { Stamp stamp = (Stamp) i.next(); stamp.cancel(); }

예를 들어 실행한 후 한참 두인 런타임에야 잘못됨을 알 수 있었다면
런타임에 문제를 겪는 코드와 원인을 제공한 코드가 물리적으로 상당히 떨어져 있을 가능성이 커지고
ClassCastException 발생시 stamps에 동전을 넣은 지점을 찾기 위해 코드 전체를 훑어봐야하는 비 효율적인 상황이 발생할 수 있다.

위 코드 주석인 // Stamp 인스턴스만 취급. 은 컴파일러는 이해하지 못하므로 큰 도움이 되지 못함

해결책

제네릭을 활용하여 위 코드의 주석 정보가 타입 선언 자체에 녹아들게 해보자.

private final Collection<Stamp> stamps = ...; stamps.add(new Coin(...));

위 코드로 변경 시 컴파일러는 stamps 에는 Stamp의 인스턴스만 넣어야 함을 인지하게 되고
이전 코드 처럼 stamps에 엉뚱한 Coin 인스턴스를 넣게 되면 컴파일 오류가 발생하며, 무엇이 잘못됐는지 정확히 알려준다.

즉 아무런 경고 없이 컴파일된다면 의도대로 동작할 것임을 보장한다.!!

List로 보는 예시

List 같은 로 타입은 사용해서는 안됨

• IntelliJ 에서도 로 타입 사용을 경고 하고 있음 (물론 실행에는 문제가 되지 않음)

List<Object> 처럼 임의 객체를 허용하는 매개변수화 타입은 괜찮음

• 로 타입을 사용한다는 경고는 사라졌음을 알 수 있다.

로 타입 List와 List<Object>는 무슨 차이 ? (Object도 가장 상위 타입인데 큰 차이가 없어 보이는데?)

• List(로 타입)은 제네릭 타입에서 완전히 발을 뺀 것
• List<Object>는 모든 타입을 허용한다는 의사를 컴파일러에 명확히 전달한 것

List<Object>와 List<String>의 차이

• 매개변수로 List를 받는 메서드에 List<String>을 넘길 수 있지만 List<Object>를 받는 메서드에는 넘길 수 없음.
• 제네릭 하위 타입 규칙 떄문
• List<String>은 로 타입인 List의 하위 타입이지만 List<Object>의 하위 타입은 아니기 때문 (아이템 28 참고)
• 그 결과 List<Object>는 같은 매개변수화 타입을 사용할 때와 달리 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<String> list, Object o) { list.add(o); }

위 코드는 strings.get(0)의 결과를 형변환하려 할 떄 ClassCastException을 던진다.
Integer를 String으로 변환하려 시도한 것이기 때문이다.

이 형변환은 컴파일러가 자동으로 만들어준 것이라 보통 실패하지 않는다.
하지만 이 경우 컴파일러의 경고를 무시하여 대가를 치르게 된다.

제가 직접 IntelliJ에서 실행해보니 컴파일 에러가 발생 함을 확인할 수 있다. (컴파일러에 다라 다른듯 함.)

main 메서드 내 코드는 컴파일러에서 문제가 없다고 판단하지만 unsafeAdd 메서드 내에서 list에 값을 넣을때 String 타입이 필요한데 Object 타입이 왔다는 에러를 보임

public static void main(String[] args) { List<String> strings = new ArrayList<>(); unsafeAdd(strings, Integer.valueOf(42)); } private static void unsafeAdd(List<String> list, Object o) { list.add((String) o); }

위 코드처럼 억지로 타입 변환을 시도하면 컴파일에는 문제가 되지 않지만 역시 런타임에 에러가 발생한다.

ClassCastException 에러가 발생함을 확인할 수 있다.

List<String>이 아닌 List<Object>로 코드를 수정해보자

public static void main(String[] args) { List<Object> strings = new ArrayList<>(); unsafeAdd(strings, Integer.valueOf(42)); String s = strings.get(0); } private static void unsafeAdd(List<String> list, Object o) { list.add(o); }

이 경우 무조건 컴파일이 되지 않습니다.

이러한 문제를 보니 원소의 타입을 몰라도 되는 로 타입을 쓰는게 좋은게 아닌가?? (제네릭 타입을 쓰고 싶어도 실제 타입 매개변수가 뭔지 몰라 쓸수가 없어...)

static int numElementsInCommon(Set s1, Set s2) { int result = 0; for (Object o1 : s1) { ++result; } return result; }

이 메서드는 동작은 하지만 로 타입을 사용해서 안전하지 않다.

따라서 비한정적 와일드카드 타입 (unbounded wildcard type)을 대신 사용하는 게 좋다.

즉 제네릭 타입을 쓰고 싶지만 실제 타입 매개변수가 무엇인지 신경 쓰고 싶지 않다면 물음표(?)를 사용하자

제네릭 타입인 Set<E>의 비한정적 와일드카드 타입은 Set<?> 이다.

위 코드를 수정하면

static int numElementsInCommon(Set<?> s1, Set<?> s2) { int result = 0; for (Object o1 : s1) { ++result; } return result; }

비한정적 와일드카드 타입과 로 타입의 차이?

Set<?> (비한정적 와일드카드 타입) 과 Set (로 타입)의 차이

와일드카드 타입은 안전하고 로 타입은 안전하지 않다.

• 로 타입 컬렉션에는 아무 원소나 넣을 수 있음 --> 타입 불변식을 훼손하기 쉬움
• Collection<?>에는 null 외에는 어떤 원소도 넣을 수 없음
• 다른 원소를 넣으려 할시 컴파일 오류

 Collection<?> collection = new ArrayList<>(); collection.add("abc");

컴파일 시

위와 같은 에러가 발생

보충 설명이 필요한 메시지이지만 컴파일러는 제 역할을 한 것이다.
즉 컬렉션의 타입 불변식을 훼손하지 못하도록 막았음을 알 수 있다.

• 구체적으로 null 이외에 어떤 원소도 Collection<?>에 넣지 못하게 함
• 컬렉션에서 꺼낼 수 있는 객체의 타입도 전혀 알 수 없음
• 이와 같은 제약을 받아들일 수 없다면 --> 제네릭 메서드 (아이템 30 참고) 혹은 한정적 와일드카드 타입 (아이템 31 참고) 를 사용하면 됨.

로 타입을 쓰지 말라는 규칙의 예외

1. class 리터럴에는 로 타입을 써야 함.

• 자바 명세는 class 리터럴에 매개변수화 타입을 사용하지 못하게 함. (배열과 기본 타입은 허용)
• ex) List.class, String[].class, int.class는 허용, List<String>.class, List<?>.class는 허용하지 않음

2. instanceof 연산자는 비한정적 와일드카드 타입 이외에 매개변수화 타입에는 적용할 수 없다.

• 런타임에는 제네릭 타입 정보가 지워지므로 instanceof 연산자는 비한정적 와일드카드 타입 이외의 매개변수화 타입 적용을 할 수 없음.
• 로 타입이든 비한정적 와일드카드 타입이든 instanceof는 완전히 똑같이 동작함
• 비한정적 와일드카드 타입의 꺾쇠괄호와 물음표는 아무론 역할 없이 코드만 지저분하게 만들기에 오히려 로 타입으로 쓰는 편이 더 깔끔

if (o instanceof Set) { // 로 타입 Set<?> s = (Set<?>) o; // 와일드카드 타입 }

• 위 코드는 제네릭 타입에 instanceof를 사용하는 올바른 예이다.

o의 타입이 Set임을 확인한 다음 와일드카드 타입인 Set<?>로 형변환해야 함(로 타입이 Set이 아님)
이는 검사 형변환 (checked cast)이므로 컴파일러 경고가 뜨지 않음

이렇게 좋은 제네릭의 타입 매개변수 방식을 억지로 사용하게 하면 되는게 아닌가? 왜 굳이 로 타입을 지원할까?

--> 호환성 때문

자바가 제네릭을 받아들이기까지 약 10년 걸림.
이 동안 제네릭 없이 짠 코드가 이미 자바 세상을 덮어버림.

결국 기존코드를 모두 수용하면서 제네릭을 사용하는 새로운 코드와도 맞물려 돌아가게 해야했으므로 로 타입을 만들어 놓음..

로 타입인 경우 타입 선언에서 제네릭 타입 정보가 전부 지워진 것 처럼 동작하는데
제네릭이 도래하기 전 코드와 호환되도록 하기 위한 궁여지책일 뿐이다.

정리

1. 로 타입을 사용하면 런타임에 예외가 일어날 수 있으니 사용하지 않도록.
2. 로 타입은 제네릭이 도입되기 전 코드와의 호환성을 위해 제공될 뿐
3. 로 타입(타입 매개변수가 없는 제네릭 타입)을 쓰면 제네릭이 안겨주는 안정성과 표현력을 모두 잃게 된다.

용어의 영문, 예시, 관련 용어에 대한 설명 아이템

한글 용어	영문 용어	예	아이템
매개변수화 타입	parameterized type	List<String>	아이템 26
실제 타입 매개변수	actual type parameter	String	아이템 26
제네릭 타입	generic type	List<E>	아이템 26, 29
정규 타입 매개변수	formal type parameter	E	아이템 26
비한정적 와일드카드 타입	unbounded wildcard type	List<?>	아이템 26
로 타입	raw type	List	아이템 26
한정적 타입 매개변수	bounded type parameter	<E extends Number>	아이템 29
재귀적 타입 한정	recursive type bound	<T extends Comparable<T>>	아이템 30
한정적 와일드카드 타입	bounded wildcard type	List<? extends Number>	아이템 31
제네릭 메서드	generic method	static <E> List <E> asList(E[] a)	아이템 30
타입 토큰	type token	String.class	아이템 33

[jinan159]

로 타입은 하위 호환성을 위해 어쩔 수 없이 존재하는 자바 문법상의 옥에 티 같은 존재군요..

[corock]

잘 읽었습니다.
인터페이스 + 제네릭 + 와일드카드를 함께 사용했을 때 단위 테스트 코드 작성 시에 어려움을 겪은 적이 있어요.
그때 아마 해결책이 현재로서는 없다는 것으로 결론지은 포스팅을 본 적이 있는데 링크 찾으면 공유해 드리겠습니다.