5장 제네릭 (week4)

[KimYealynn]

5장 제네릭

Schedule : 21.05.26 (수) 8:30PM => 21.06.02 (수) 8PM

목차

아이템 26. 로 타입은 사용하지 말라 아이템 27. 비검사 경고를 제거하라 아이템 28. 배열보다는 리스트를 사용하라 아이템 29. 이왕이면 제네릭 타입으로 만들라 아이템 30. 이왕이면 제네릭 메서드로 만들라 아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라 아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라 아이템 33. 타입 안전 이종 컨테이너를 고려하라

[minSW]

5장 제네릭

item 26

• 제네릭 타입(Generic Type)
  • 클래스와 인터페이스 선언에 타입 매개변수가 쓰이는 제네릭 클래스, 제네릭 인터페이스 통칭 (> java 5)
  • 일련의 '매개변수화 타입 (parameterized type)' 정의 (ex. List<E>)
• 타입 매개변수(type parameter)

  List<E> // E => 정규 타입 매개변수
  List<String> // String => 실제 타입 매개변수

• 로 타입 (raw type) 은 타입 매개변수가 아님 (ex. List) => 즉, 제네릭이 아님
• Why not use 로타입?
  • 안전 x (컴파일 오류감지 x). just use for 호환성 (java5 미만)
• 임의 객체 허용은 가능함 (ex. List<Object>)
  • 모든 객체 가능한 매개변수화 타입
• 비한정적 와일드 카드 타입 (ex. List<?>)
  • null 빼고 어떤원소도 넣을 수 없다. => 모종의 타입객체만 가능
  • 와일드 카드 : "어떤 타입이 오든 난 모르겠고, 타입과 관계없는 기능만 수행하겠다."
  • ref. https://vvshinevv.tistory.com/55 참고
• 로타입 사용 케이스
  • class 리터럴 : List.class (o) vs List<String>.class (x)
  • instanceof : 로타입이든 비한정적 와일드카드 타입이든 동일 동작하므로 이왕이면 깔끔하게. (ex. o instanceof List)

List<String>                    // 매개변수화 타입 (+ 실제 타입 매개변수)
List<E>                         // 제네릭 타입 (+ 정규 타입 매개변수)
List<?>, List<? extends Number> // 비한정적/한정적 와일드카드 타입

List                            // 로 타입 (제네릭x)
String.class                    // 타입 토큰

<E>                         // 정규 타입 매개변수
<String>                    // 실제 타입 매개변수
<E extends Number>          // 한정적 타입 매개변수
<T extends Comparable<T>>   // 재귀적 타입 한정

static <E> List<E> asList(E[] a)  // 제네릭 메서드

item 27

• 타입 매개변수 추론 <>
• 가능한 모든 비검사 경고 제거할 것 (경고가 없다 == 코드가 '타입 안정성'을 보장한다)
• @SuppressWarnings("unchecked") => 가능한 좁은 범위에. 주석과 함께

item 28

• 배열 vs 리스트 (제네릭)
  • 배열 : 공변 (covariant). 실체화 (reify) 가능 (런타임에도 본인의 원소 타입 인지, 확인 가능)
  • 제네릭 : 불공변 (invariant). 런타임 시 타입 정보 소거 (erasure) 됨. (컴파일시 타입을 알수 있지만 런타임 시엔 타입정보 소거)
• 공변
  • 공변성 (Covariant) : X -> Y 이면, C\<X> → C\<Y>
  • 반공변성 (Contravariant) : X -> Y 이면, C\<Y> → C\<X>
  • 불공변 (Invariant) : X -> Y 이더라도 불가능 (C\<X> != C\<Y>)
• 제네릭 배열은 생성 불가 (ClassCastException)
  • 비한정적 와일드카드 타입(List<?>)은 배열로 만들 수 있지만 굳이..
• 실체화
  • 실체화 불가 타입 : E, List\<E>, List\<String> (소거 때문)
  • 실체화 가능 타입 : List\<?>, Map\<?, ?>
• E[] => List\<E> : 타입안정성, 상호운용성 ↑
  • 배열은 런타임엔 type-safe, 컴파일엔 x
  • 제네릭은 컴파일엔 type-safe, 런타임엔 x (반대)
• 제네릭의 장점은 오류를 런타임이 아닌 컴파일에 알게해준다는게 장점인 듯.

item 29

• p.173 "하지만 (E가 Object가 아닌 한) 배열의 런타임 타입이 컴파일타임 타입과 달라 힙 오염(Heap pollution) 을 일으킨다."
• 힙 오염 (Heap Pollution) : 매개변수화 타입의 변수가 타입이 다른 객체를 참조하는 경우 발생
  • => 컴파일러로 인해 자동 생성된 형변환으로 ClassCastException 발생
  • 🤔 힙에 미치는 영향이나 오염의 의미에 대한 언급은 따로 찾지못함
  • ref. https://en.wikipedia.org/wiki/Heap_pollution
• vs item 28 "배열보다 리스트를 우선해라"
  • 현실은 제네릭 타입 내 리스트 사용이 항상 가능한것도, 꼭 더 좋은 것도 아님
  • 내부 구현이 어차피 배열이기도
• 한정적 타입 매개변수 (ex. <E extends _ >)

item 30

• 명시적 형변환 메서드보다는 이왕이면 '제네릭 메서드'
• 타입 매개변수 명명규칙
  • T: 임의의 타입, Type
  • E: 컬렉션 원소의 타입, Element
  • K: 맵의 Key
  • V: 맵의 Value
  • X: 예외, eXception
  • R: 메서드의 반환 타입, Return
  • T, U, V, T1, T2, T3: 임의 타입의 시퀀스
  • ref. (item 68), https://madplay.github.io/post/adhere-to-generally-accepted-naming-conventions
• 제네릭 메서드

                  // (2) 반환타입 + 집합의 원소타입 E => (1)로 명시
  public static <E> Set<E> union(Set<E> s1, Set<E> s2) { .. }
            //(1) 타입매개변수 목록
        // (위치는 제한자와 반환타입 사이)

• p.177 제네릭 싱글턴 팩터리
  • 여러 타입에 적합한 객체 생성 (타입별 하나씩 생성 필요 x)

    private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;

• 재귀적 타입한정 : <E extends Comparable<E>> == "모든 타입 E는 자신과 비교 가능"
• p.180 "관용구, 와일드 카드를 사용한 변형, 셀프타입 관용구.."
  • 관용구 (idiom) : 자주 사용하는 코딩 형태나 패턴 ?
  • 셀프 타입 관용구 => "self 타입이 없는 자바를 위한 우회방법 (p.20 in item 2)"

item 31

• 매개변수화 타입은 불공변(invariant) => 리스코프 위배
  • "유연성을 극대화하려면 생산자 or 소비자용 입력 매개변수에 와일드카드 타입을 사용해라"
  • 단, 생산자 and 소비자인 입력 매개변수면 타입을 명확히 지정해야함 => 와일드카드 x
• 한정적 와일드 카드
  • 반환타입에서는 사용 불가. 입력에서 사용

    Iterable<E>             // E의 Iterable
    Iterable<? extends E>   // E의 하위타입의 Iterable
    Collection<? super E>   // E의 상위타입의 Collection

• PECS : producer-extends, consumer-super (Get and Put Principle)
  • 매개변수화 타입 T가...
  • 생상자면 => <? extends T>
  • 소비자면 => <? super T>
  • Comparable<? super E>, Comparator<? super E> 는 항상 소비자
• p.186-7 PECS 적용 예제
• 목표 타이핑 (target typing) : Java 8 부터 강력한 타입추론 가능
  • java7까진 명시적 타입인수 필요 (ex. Union.<Number>union();

• 매개변수 (parameter) vs 인수 (argument)

  • 매개변수 (parameter) : 메서드 선언에 정의한 변수
  • 인수 (argument) : 호출시 넘기는 실제값

    
    void add(int value) {...}   // value = 매개변수 (parameter)
    add(10);                    // 10 = 인수 (argument)

  class Set {...} // T = 타입 '매개변수' Set = ..; // Intger = 타입 '인수'

• 타입 매개변수 <E> vs 와일드 카드 <?>
  • 메서드 선언에 타입 매개변수가 한번만 나오면 => 와일드 카드 사용
  • 와일드 카드 사용 시 외부에서는 더 유연하고 단순하게 사용 가능 (내부적으로는 다시 타입 매개변수를 이용하는 복잡한 제네릭 메서드를 쓰더라도..)

item 32

• 가변인수(varargs) 메서드
  • => 배열 노출됨 (완벽 추상화x)
  • 🤔List도 Object인가? (Collection이니까?)
• code 28-3 vs code 32-1
  • [28] 제네릭 배열 생성불가. 허용 시 컴파일은되는데 런타임에서 에러발생 (배열은 공변)
  • [32] 제네릭 varargs 매개변수 받는 메서드 허용 => 유용해서 ^^% 모순 수용~
• @SafeVarargs
  • varargs 목적대로만 쓰일때 (순수한 인수전달용) => 타입 안정 보장
  • 아무것도 저장 x. 밖 노출 x (신뢰가능하거나 가변인수를 받지않는 메서드로 노출은 o)
  • (위험한 노출 예 : static <T> T[] toArray (T... args))

item 33

• 매개변수화 되는건 컨테이너 자신 (원소 x)

• 임의 개수의 원소가 필요한 경우 (ex. db의 column)

  • 모두 Type-safe하려면 컨테이너 대신 키를 매개변수화

    public class SampleHaterogeneousContainer {
    priavet Map<Class<?>, Object> map = new HashMap<>(); // 키가 비한정적 와일드 카드 (Map이 와일드카드 x)
    
    public <T> void put(Class<T> type, T instance);
    public <T> T get(Class<T> type);
    }

• class 의 클래스는 제네릭 (Class<T>)
  • class 리터럴 (ex. String.class) => 타입 토큰 (type token) => 키로 사용
• java printf("%n")
• 키와 값 사이 타입 링크(Type Linkable) 정보는 없어짐
  • get 할때, 동적 형변환(cast())로 관계를 되살릴수 있음 (비검사 형변환 필요 x)
• 제약 2가지
  • 로타입 넘길시, put 은 가능, get 할 때 비검사 경고 => 동적형변환 사용 or Collection 의 checked- 래퍼 사용
  • 실체화 불가 타입에 사용 x (소거때문, ex. List\<Interger>.class == List\<String>.class) => 슈퍼 타입 토큰 사용
• 슈퍼 타입 토큰 (super type token)
  • Neal Gafter의 글 - "Super Type Tokens" (+ 슈퍼 타입 토큰의 한계)
  • 구현체 : Spring의 ParameterizedTypeReference
  • 슈퍼 타입을 토큰으로 사용가능 (상속 + Reflection)
  • ref. https://sungminhong.github.io/spring/superTypeToken/
  • ref. https://yangbongsoo.gitbook.io/study/super_type_token

• 한정적 타입 토큰도 사용 가능

  • 예 : Annotation API
  • Annotation API의 리플랙션 대상 타입 : 클래스, 메서드, 필드 (java.lang.Class\<T>, java.lange.reflect.Method, java.lange.reflect.Field)

    
    // 애너테이션 요소 = 키가 에너테이션 타입인 타입 안전 이종 컨테이너
    public <T extends Annotation> T getAnnotation(Class<T> annotationType) {...};
                                                // annotationType => 애너테이션 타입을 뜻하는 한정적 타입 토큰
    AnnotatedElement element;
    element.getAnnotation(annotateType.asSubclass(Annotation.class));
    // asSubclass() : Class<?> => Class<? extends Annotation> 으로 형변환한 것 과 동일