반응형
Jake Seo
제이크서 위키 블로그
Jake Seo
전체 방문자
오늘
어제
  • 분류 전체보기 (715)
    • 일상, 일기 (0)
    • 백준 문제풀이 (1)
    • 릿코드 문제풀이 (2)
    • 알고리즘 이론 (10)
      • 기본 이론 (2)
      • 배열과 문자열 (8)
    • 데이터베이스 (15)
      • Planet Scale (1)
      • MSSQL (9)
      • 디비 기본 개념 (1)
      • SQLite 직접 만들어보기 (4)
    • 보안 (7)
    • 설계 (1)
    • 네트워크 (17)
      • HTTP (9)
      • OSI Layers (5)
    • 회고 (31)
      • 연간 회고 (2)
      • 주간 회고 (29)
    • 인프라 (52)
      • 도커 (12)
      • AWS (9)
      • 용어 (21)
      • 웹 성능 (1)
      • 대규모 서비스를 지탱하는 기술 (9)
    • 깃 (7)
    • 빌드 도구 (7)
      • 메이븐 (6)
      • 그레이들 (0)
    • Java (135)
      • 이펙티브 자바 (73)
      • 자바 API (4)
      • 자바 잡지식 (30)
      • 자바 디자인 패턴 (21)
      • 톰캣 (Tomcat) (7)
    • 프레임워크 (64)
      • next.js (14)
      • 스프링 프레임워크 (28)
      • 토비의 스프링 (6)
      • 스프링 부트 (3)
      • JPA (Java Persistence API) (5)
      • Nest.js (8)
    • 프론트엔드 (48)
      • 다크모드 (1)
      • 노드 패키지 관리 매니저 (3)
      • CSS (19)
      • Web API (11)
      • tailwind-css (1)
      • React (5)
      • React 새 공식문서 요약 (1)
      • HTML (Markup Language) (5)
    • 자바스크립트 (108)
      • 모던 자바스크립트 (31)
      • 개념 (31)
      • 정규표현식 (5)
      • 코드 스니펫 (1)
      • 라이브러리 (6)
      • 인터뷰 (24)
      • 웹개발자를 위한 자바스크립트의 모든 것 (6)
      • 팁 (2)
    • Typescript (49)
    • 리눅스와 유닉스 (10)
    • Computer Science (1)
      • Compiler (1)
    • IDE (3)
      • VSCODE (1)
      • IntelliJ (2)
    • 세미나 & 컨퍼런스 (1)
    • 용어 (개발용어) (16)
      • 함수형 프로그래밍 용어들 (1)
    • ORM (2)
      • Prisma (2)
    • NODEJS (2)
    • cypress (1)
    • 리액트 네이티브 (React Native) (31)
    • 러스트 (Rust) (15)
    • 코틀린 (Kotlin) (4)
      • 자바에서 코틀린으로 (4)
    • 정규표현식 (3)
    • 구글 애널리틱스 (GA) (1)
    • SEO (2)
    • UML (2)
    • 맛탐험 (2)
    • 리팩토링 (1)
    • 서평 (2)
    • 소프트웨어 공학 (18)
      • 테스팅 (16)
      • 개발 프로세스 (1)
    • 교육학 (1)
    • 삶의 지혜, 통찰 (1)
    • Chat GPT (2)
    • 쉘스크립트 (1)
    • 컴파일 (2)
    • Dart (12)
    • 코드팩토리의 플러터 프로그래밍 (4)
    • 플러터 (17)
    • 안드로이드 스튜디오 (1)
    • 윈도우즈 (1)
    • 잡다한 백엔드 지식 (1)
    • 디자인 패턴 (1)

블로그 메뉴

  • 홈
  • 태그
  • 방명록

공지사항

인기 글

태그

  • 메이븐 골
  • Pre-rendering
  • 싱글톤 패턴
  • Next.js
  • 스프링 검증
  • 싱글톤
  • 알고리즘
  • 이펙티브자바
  • serverless computing
  • 플라이웨이트패턴
  • 이펙티브 자바
  • 토비의 스프링
  • item9
  • 이펙티브 자바 item9
  • 슬로우 쿼리
  • 자바스크립트 면접
  • bean Validation
  • rust
  • 자바 검증
  • item8
  • 싱글턴
  • item7
  • 자바
  • MSSQL
  • Javadoc 자바독 자바주석 주석 Comment
  • 추상 팩터리 패턴
  • 프로그래머의 뇌
  • 자바스크립트 인터뷰
  • 메이븐 라이프사이클
  • 메이븐 페이즈
  • NEXT JS
  • Java
  • prerendering
  • 외래키 제약조건
  • 팩터리 메서드 패턴
  • 빈 검증
  • 참조 해제
  • 서버리스 컴퓨팅
  • try-with-resources
  • 러스트
  • 자바스크립트
  • 자료구조
  • 도커공식문서
  • pnpm
  • 자바 디자인패턴
  • next js app
  • 디자인패턴
  • 객체복사
  • 느린 쿼리
  • 작업기억공간

최근 댓글

최근 글

티스토리

hELLO · Designed By 정상우.
Jake Seo

제이크서 위키 블로그

Java/이펙티브 자바

이펙티브 자바, 쉽게 정리하기 - item 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

2022. 1. 24. 21:53

이펙티브 자바, 쉽게 정리하기 - item 31. 한정적 와일드카드를 사용해 API 유연성을 높이라

와일드 카드 타입을 사용해야 하는 이유

  • 제네릭은 불공변이다.
    • 하위 혹은 상위 타입을 기본적으로는 포용하지 않게 되어있다.
    • 필요하다면, extends 혹은 super를 이용하면 된다.
static class StackWithGeneric<E> {
    private E[] elements;
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    public StackWithGeneric() {
        elements = (E[])  new Object[DEFAULT_INITIAL_CAPACITY];
    }

    public void push(E e) {
        ensureCapacity();
        elements[size++] = e;
    }

    /* 새로 추가된 메서드 */
    public void pushAll(Iterable<E> src) {
        for (E e : src) {
            push(e);
        }
    }

    public E pop() {
        if (size == 0) {
            throw new EmptyStackException();
        }

        E result = elements[size];
        elements[size] = null;

        return result;
    }

    private void ensureCapacity() {
        if(elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }

    @Override
    public String toString() {
        return "StackWithGeneric{" +
                "elements=" + Arrays.toString(elements) +
                ", size=" + size +
                '}';
    }
}
  • pushAll이라는 메서드를 새로 추가하였다.
public void pushAll(Iterable<E> src) {
    for (E e : src) {
        push(e);
    }
}
  • 보기엔 별 문제 없어보인다.
  • 그러나 다음 클라이언트 코드를 작성하면 에러가 난다.

불공변인 제네릭코드 예제

@Test
public void stackTest() {
    StackWithGeneric<Number> stack = new StackWithGeneric<>();
    List<Integer> integers = List.of(1, 2, 3);
    stack.pushAll(integers);
    System.out.println("stack = " + stack);
}
  • 위 코드는 에러가 난다. Number 타입의 스택에 Integer는 하위타입이기에 들어갈 수 있다고 생각하지만, 제네릭이 불공변이어서 에러가 난다.

생산자 버전: 한정적 와일드 카드 타입을 통해 불공변 제네릭 유연하게 만들기

public void pushAll(Iterable<? extends E> src) {
    for (E e : src) {
        push(e);
    }
}
  • pushAll()을 위와 같이 바꾸면, 더이상 에러가 나지 않는다.
    • 단순히 E만 이용했을 때는 Number만 받을 수 있지만, 이제 Integer도 받을 수 있다.
  • ? 와일드카드 타입으로 E를 상속한 아무 타입이나 받아줄 수 있다.
    • 제네릭의 불공변 때문에 이렇게 한정적 와일드카드 타입(? extends E)을 이용해주는 것이 좋다.

소비자 버전: 한정적 와일드 카드 타입을 통해 불공변 제네릭 유연하게 만들기

public void popAll(Collection<E> dst) {
    while(size > 0) {
        dst.add(pop());
    }
}

@Test
public void stackTest() {
    StackWithGeneric<Number> stack = new StackWithGeneric<>();
    List<Integer> integers = List.of(1, 2, 3);
    // produce
    stack.pushAll(integers);
    System.out.println("stack = " + stack);

    Collection<Object> objects = new ArrayList<>();
    stack.popAll(objects);
}
  • popAll()도 위의 pushAll() 케이스와 비슷하게, 제네릭의 불공변 특성 때문에 에러가 나는 케이스이다.
  • 불공변덕에 StackWithGeneric의 제네릭이 Number였어서 유연성 없이 Collection<Number> 타입만을 인수로 받을 수 있는데, 상위 타입인 Object가 와서 문제인 것이다.
  • 소비자의 경우, 생산자와 다르게 상위 클래스로만 유연하게 확장해야 한다.
    • 클래스가 가진 컬렉션 필드에 수용할 때는 많은 정보 중 필요한 정보만 취사선택 하면 된다. (생산자 관점)
      • 정보가 더 많아서 나쁠 게 없다. (상위 타입은 하위 타입을 수용할 수 있다. 상속 덕에 필요한 정보가 이미 다 있다.)
    • 클래스가 가진 컬렉션 필드를 꺼내올 때는 해당 컬렉션이 가진 정보를 받아줄 객체가 필요하다. (소비자 관점)
      • 상위 객체만이 하위 객체를 받아줄 수 있다. (하위 타입은 상위 타입을 수용할 수 없다. 더 많은 정보가 필요하다.)
    • 그러므로 와일드카드에 super 키워드를 사용해야 한다.
public void popAll(Collection<? super E> dst) {
    while(size > 0) {
        dst.add(pop());
    }
}
  • 위와 같이 작성하면 아무런 에러 없이 잘 작동된다.

생산자와 소비자 패턴에서 제네릭의 형태

  • 상위 타입일수록 더 적은 정보를 가지고 있다. 하위 타입일수록 더 구체적인 다른 정보를 많이 가지고 있다.
  • 생산자일 때는 하위 타입을 받아도 객체는 필요한 정보만 쓰면 되니, extends를 쓴다.
  • 소비자일 때는 소비자의 정보를 받아줄 타입이 필요 하니, super를 쓴다.
  • 만일 매개변수가 생산자와 소비자 둘의 역할을 모두 하면, 어느것을 써도 좋을 것이 없기 때문에 그냥 정확한 타입을 써야 한다.
    • 생산을 해야 하는데 상위 객체가 온다면 정보가 부족하고, 소비를 해야 하는데 하위 객체가

위와 같이 생산자(producer)에는 extends, 소비자(consumer)에는 super를 쓴다고 해서 PECS라고 부른다.

약간 특이한 케이스: Comparable의 제네릭 타입

  • Comparable은 항상 소비자의 입장이다. PECS 원칙에 따라 super를 쓰는 것이 좋다.

super를 사용하지 않은 Comparable의 예

public static <E extends Comparable<E>> E max(List<E> list);
  • 겉보기엔 크게 문제가 없어보인다.
  • 그러나 아래 코드를 보면 생각이 좀 달라질 수 있다.
static class Student extends Person {
    private final int grade;

    public Student(String name, int age, int grade) {
        super(name, age);
        this.grade = grade;
    }
}
  • Student 클래스는 Person 클래스와 공통 요소를 가지고 있어 Comparable<Student>를 구현한 것이 아니라, Comparable<Person>을 구현했다.
  • 이럴 때는 Person 객체의 비교 기준으로 max 메서드를 사용하려면 아래와 같이 선언해주어야 한다.
public static <E extends Comparable<? super E>> E max(List<E> list);
  • 이제 상위 객체 기준으로 Comparable을 상속하였어도 정상적으로 동작한다.
@Test
public void compareStudentTest() {
    Student student1 = new Student("john", 15, 1);
    Student student2 = new Student("jonna", 16, 2);
    Student student3 = new Student("kane", 14, 0);
    Student student4 = new Student("toto", 17, 3);
    Student student5 = new Student("momo", 15, 1);

    List<Student> students = new ArrayList<>(List.of(student1, student2, student3, student4, student5));

    System.out.println("students = " + students);
    System.out.println("max(students) = " + max(students));
}

결과

students = [Student{name='john', age=15, grade=1}, Student{name='jonna', age=16, grade=2}, Student{name='kane', age=14, grade=0}, Student{name='toto', age=17, grade=3}, Student{name='momo', age=15, grade=1}]
max(students) = Student{name='toto', age=17, grade=3}
  • 가장 나이가 많은 학생인 toto가 잘 뽑힌 것을 볼 수 있다.

메서드 선언에 타입 매개변수가 한번만 나온다면 와일드 카드를 쓰자.

  • 메서드 선언에 타입 매개변수가 단 한번만 나온다면, 와일드 카드를 썼을 때 그 의도가 더 명확하다.
@Test
public void methodSignatureWildcardTest() {
    List<String> strings = new ArrayList<>(List.of("a", "b", "c", "d", "e", "f"));
    swap(strings, 0, 1);
    System.out.println("strings = " + strings);
}

public static void swap(List<?> list, int i, int j) {
    swapHelper(list, i, j);
}

private static <E> void swapHelper(List<E> list, int i, int j) {
    list.set(i, list.set(j, list.get(i)));
}
  • 그냥 ? 와일드카드 타입만 쓰면, list.add()가 불가능하기에, showHelper()라는 도우미 메서드를 만들었다.
  • 위와 같이 코드를 구성하면, API 외부로는 ? 와일드카드가 보이고, 내부에서는 <E> 타입을 쓰게 된다.

핵심 정리

  • 조금 복잡하더라도 와일드카드 타입을 적용하면 API가 훨씬 유연해진다.
  • 널리 쓰일 라이브러리엔 반드시 와일드카드 타입을 적용하자.
  • 생산자에는 extends 소비자에는 super를 사용하는 PECS를 기억하자.
반응형
저작자표시 (새창열림)

'Java > 이펙티브 자바' 카테고리의 다른 글

이펙티브 자바, 쉽게 정리하기 - item 33. 타입 안전 이종 컨테이너를 고려하라  (0) 2022.01.24
이펙티브 자바, 쉽게 정리하기 - item 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라  (0) 2022.01.24
이펙티브 자바, 쉽게 정리하기 - item 30. 이왕이면 제네릭 메서드로 만들라  (0) 2022.01.09
이펙티브 자바, 쉽게 정리하기 - item 29. 이왕이면 제네릭 타입으로 만들라  (0) 2022.01.09
이펙티브 자바, 쉽게 정리하기 - item 28. 배열보다는 리스트를 사용하라  (0) 2022.01.09
    'Java/이펙티브 자바' 카테고리의 다른 글
    • 이펙티브 자바, 쉽게 정리하기 - item 33. 타입 안전 이종 컨테이너를 고려하라
    • 이펙티브 자바, 쉽게 정리하기 - item 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라
    • 이펙티브 자바, 쉽게 정리하기 - item 30. 이왕이면 제네릭 메서드로 만들라
    • 이펙티브 자바, 쉽게 정리하기 - item 29. 이왕이면 제네릭 타입으로 만들라
    Jake Seo
    Jake Seo
    ✔ 잘 보셨다면 광고 한번 클릭해주시면 큰 힘이 됩니다. ✔ 댓글로 틀린 부분을 지적해주시면 기분 나빠하지 않고 수정합니다. ✔ 많은 퇴고를 거친 글이 좋은 글이 된다고 생각합니다. ✔ 간결하고 명료하게 사람들을 이해 시키는 것을 목표로 합니다.

    티스토리툴바