티스토리 뷰
배열과 리스트의 차이점 1
- 배열은 공변(covariant)이다. (함께 변한다.)
- Sub가 Super의 하위 타입이라면 Sub[]는 Super[]의 하위 타입이 된다.
- 제네릭은 불공변(invariant)이다. (함께 변하지 않는다.)
- 서로 다른 타입 Type1, Type2가 있을 때, List은 List의 하위타입도 상위타입도 아니다.
// 런타임에 실패한다.
Object[] objectArray = new Long[1];
objectArray[0] = "타입이 달라 넣을 수 없다."; // ArrayStoreException을 던진다.
// 컴파일에 실패한다.
List<Object> ol = new ArrayList<Long>(); // 호환되지 않는 타입이다.
ol.add("타입이 달라 넣을 수 없다.");
두 가지 방법 모두 Long 용 저장소에 String 을 넣을 수는 없다.
다만 배열은 런타임에, 리스트는 컴파일할 때 알 수 있다.
언제나 그렇듯 에러는 빨리 알아차리는게 좋기에 컴파일 타임이 좋다.
배열과 리스트의 차이점 2
- 배열은 실체화(reify) 된다.
- 배열은 런타임에도 자신이 담기로 한 원소의 타입을 인지하고 확인한다.
- 제네릭은 타입 정보가 런타임에는 소거(erasure) 된다.
- 원소 타입을 컴파일타임에만 검사하며 런타임에는 알 수 조차 없다는 뜻이다.
이상의 주요 차이로 인해 배열과 제네릭은 잘 어우러지지 못한다.
예컨대 배열은 제네릭 타입, 매개변수화 타입, 타입 매개변수로 사용할 수 없다.
ex. new List[], new List[], new E[]
제네릭 배열을 막은 이유는 타입 안전하지 않기 때문이다.
이를 허용한다면 컴파일러가 자동 생성한 형변환 코드에서 런타임에 ClassCastException이 발생할 수 있다.
런타임에 ClassCastException이 발생하는 일은 막아주겠다는 제네릭의 타입 시스템의 취지에 어긋나는 것이다.
E, List, List 같은 타입을 실체화 불가 타입 (non-reifiable type)이라 한다.
쉽게말해, 실체화되지 않아서 런타임에는 컴파일타임보다 타입 정보를 적게 가지는 타입이다.
소거 메커니즘 때문에 매개변수화 타입 가운데 실체화될 수 있는 타입은 List<?>, Map 같은 비한정적 와일드카드 타입뿐이다.
배열로 형변환할 때 제네릭 배열 생성 오류나 비검사 형변환 경고가 뜨는 경우 대부분은 배열 E[] 대신 컬렉션인 List를 사용하면 해결된다.
예시를 보자.
public class Chooser1 {
private final Object[] choiceArray;
public Chooser1(Collection choices) {
this.choiceArray = choices.toArray();
}
public Object choose() {
Random random = ThreadLocalRandom.current();
return choiceArray[random.nextInt(choiceArray.length)];
}
}
- choose() 를 호출할 때마다 반환된 Object를 원하는 타입으로 형변환해야 한다.
- 혹시나 타입이 다른 원소가 들어있다면 런타임에 형변환 오류가 날 것이다.
public class Chooser2<T> {
private final T[] choiceArray;
public Chooser2(Collection<T> choices) {
this.choiceArray = (T[]) choices.toArray(); // 컴파일 경고
}
public T choose() {
Random random = ThreadLocalRandom.current();
return choiceArray[random.nextInt(choiceArray.length)];
}
}
- 제네릭으로 만들어보았다.
- T가 무슨 타입인지 알 수 없으니 컴파일러는 이 형변환이 런타임에도 안전한지 보장할 수 없다고 경고가 뜬다.
- 동작은 하지만, 컴파일러가 안전을 보장하지 못한다.
- 안전하다고 확신한다면 주석을 남기고 @SuppresWarning 을 달아 경고를 숨겨도 되지만 애초에 경고의 원인을 제거하는 편이 훨씬 낫다.
public class Chooser3<T> {
private final List<T> choiceList;
public Chooser3(Collection<T> choices) {
this.choiceList = new ArrayList<>(choices);
}
public T choose() {
Random random = ThreadLocalRandom.current();
return choiceList.get(random.nextInt(choiceList.size()));
}
}
- 배열 대신 List 를 사용하니 비검사 형변환 경고가 제거 되었다.
- 코드 양이 조금 늘고 조금 더 느릴 수 있지만, 런타임에 ClassCastException을 만날 일이 없으니 가치있다.
결론
- 배열은 공변이고 실체화 된다.
- 제네릭은 불공변이고 타입 정보가 소거된다.
- 그 결과 배열은 런타임에는 타입 안전하지만 컴파일 타임에는 그렇지 않다.
- 제네릭은 런타임에는 안전하지 않지만 컴파일 타임에는 안전하다.
- 그래서 둘을 섞어 쓰기 어려우니, 배열을 리스트로 대체하는 방법을 적용해보자.
'책 > 이펙티브자바' 카테고리의 다른 글
아이템 57. 지역변수의 범위를 최소화하라 (0) | 2021.09.15 |
---|---|
아이템29. 이왕이면 제네릭 타입으로 만들라 (0) | 2021.09.01 |
아이템41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라 (0) | 2021.08.31 |
아이템40. @Override 애너테이션을 일관되게 사용하라 (0) | 2021.08.31 |
아이템39. 명명 패턴보다 애너테이션을 사용하라 (0) | 2021.08.31 |
링크
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
TAG
- 백기선 스터디
- REST API
- 킹수빈닷컴
- 가상 면접 사례로 배우는 대규모 시스템 설계 기초
- GCP
- 김영한 http
- JPA 연관관계 매핑
- ㅇㄷㅇㅈ
- BOJ
- 이펙티브자바 아이템59
- 이펙티브자바 스터디
- dreamcoding
- js api
- 패스트캠퍼스 컴퓨터공학 완주반
- 프로그래머스 SQL
- 드림코딩
- JS 딥다이브
- js promise
- 모던자바스크립트
- HTTP 완벽 가이드
- Spring Security
- http
- 프로그래머스
- 이펙티브자바 아이템60
- 김영한 JPA
- HTTP 완벽가이드
- js array
- 백준
- 이펙티브자바
- java
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |
글 보관함