[5주차] 29-36

Joshua Bloch 저 이복연 역 「Effective Java 3rd Edition, 2018」를 읽고 정리하였습니다.

29 이왕이면 제네릭 타입으로 만들라 - 발

step 1

item 7의 Stack을 제너릭으로 만들어보자

step 2 - 제너릭으로 가는 첫단계

문제 - E와 같은 실체화 불가 타입으로 배열을 만들수 없다. 배열을 제너릭으로 만들려할때 일반적인 문제.

step 3 - 해결1: 제너릭 배열 생성을 금지하는 제약을 대놓고 우회하는 방법

Object 배열을 생성한 다음 제너릭 배열로 형변환. = 우회 unchecked cast가 나온다. 하지만 push 메서드를 통해 배열에 저장되는 원소의 타입은 항상 E이다. 다시말해, elements는 push(E)로 넘어온 E 인스턴스만 담는다. 따라서 이 비검사 형변환은 확실히 안전하다 -> SuppressWarnings 사용 그런데 타입 안정성은 보장하지만 런타임 타입은 E[]가 아닌 Object[]다!

Stack<String> stack = new Stack<>(); //타입 인수 String으로 적용
System.out.println(stack.getClass().getDeclaredField("elements").getType()); //Object가 나온다.

step 4 - 해결2: elements 필드의 타입을 E[ ]에서 Object[ ]로 바꾸는것

E는 실체화 불가 타입 -> 컴파일러는 런타임에 이뤄지는 형변환이 안전한지 증명할 방법 x. 직접 증명하고 경고를 숨기자. Item 27에 따라 비검사 형변환 수행하는 할당문에서만 숨기자.

• step 3 장단점

  • 장: 가독성 좋다. 코드도 짧다. 형변환 배열 생성시 한번. (현업에서 선호)

  • 단: 힙오염 발생. (E가 Object가 아닌한) 배열의 런타임 타입이 컴파일타임과 달르기 때문.

• step 4 장단점

  • 장: 힙오염 안됨.

  • 단: 배열에서 원소를 읽을 때마다 형변환.

//step 3 - 제너릭 배열 생성을 금지하는 제약을 대놓고 우회하는 방법
//step 4 - elements 필드의 타입을 E[ ]에서 Object[ ]로 바꾸는 것
public class Stack {
//public class Stack<E> { //step 2,3,4
    private Object[] elements; //step 4+
//    private E[] elements; //step 2
    private int size = 0;
    private static final int DEFAULT_INITIAL_CAPACITY = 16;

    //@SuppressWarnings("unchecked") //step 3, 4-
    public Stack() {
        elements = new Object[DEFAULT_INITIAL_CAPACITY]; //step 4+
        //elements = new E[DEFAULT_INITIAL_CAPACITY]; //step 2 - 제너릭 배열 생성 x, 3-, 4-
        //elements = (E) new Object[DEFAULT_INITIAL_CAPACITY]; //step 3, 4-
    }
    public void push(Object e) {
    //public void push(E e) { //step 2, 3
        ensureCapacity();
        elements[size++] = e;
    }
    public Object pop() {
    //public E pop() { //step 2, 3, 4
        Object result = elements[--size];
        //E result = elements[--size];//step 2, 3
        //@SuppressWarnings("unchecked") E result = (E) elements[--size]; //step 4
        elements[size] = null;
        return result;
    }
    public boolean isEmpty() {
        return size == 0;
    }
    private void ensureCapacity() {
        if (elements.length == size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
}

30 이왕이면 제네릭 메서드로 만들라 - 발표

제네릭 메소드는 매개 타입과 리턴 타입으로 타입 파라미터를 갖는 메소드를 말합니다. 클래스와 마찬가지로, 메서드도 제네릭으로 만들 수 있다. 예, Collection 알고리즘 메서드(binarySearch, sort).

// Create a list of strings 
        ArrayList<String> al = new ArrayList<String>(); 
        al.add("Geeks For Geeks"); 
        al.add("Friends"); 
        al.add("Dear"); 
        al.add("Is"); 
        al.add("Superb"); 

        Collections.sort(al, Collections.reverseOrder()); 

        System.out.println(al); 
//결과: [Superb, Is, Geeks For Geeks, Friends, Dear]

아래는 문제있는 메서드.

// 합집합 반환
public class Union {
    public static Set union(Set s1, Set s2) {
        Set result = new HashSet(s1);
        result.addAll(s2);
        return result;
    }

    public static void main(String[] args) {
        Set s1 = Set.of("a", "b", "c");
        Set s2 = Set.of("d", "e", "f");
        Set unionSet = Union.union(s1,s2);
        System.out.println(unionSet);
    }
}

// 컴파일은 되지만 두개 경고 발생
Union.java:5: warning: [unchecked] unchecked call to
HashSet(Collection<? extends E>) as a member of raw type HashSet
    Set result = new HashSet(s1);
                ^
Union.java:6: warning: [unchecked] unchecked call to
addAll(Collection<? extends E>) as a member of raw type Set
    result.addAll(s2);
                ^

타입 안전하게 만들자.

public class Union {
    // 제너릭 코드 - 타입 매개변수 목록은 static과 Set<E>사이, 메서드의 제한자-반환타입 사이
    // 세 집합의 타입이 모두 같아야한다.
    public static <E> Set<E> union(Set<E> s1, Set<E> s2) {
        Set<E> result = new HashSet<>(s1);
        result.addAll(s2);
        return result;
    }

    // 형변환하지 않아도 컴파일 잘된다.
    public static void main(String[] args) {
        Set<String> guys = Set.of("Tom", "Dick", "Harry");
        Set<String> stooges = Set.of("Larry", "Moe", "Curly");
        Set<String> aflCio = union(guys, stooges);
        System.out.println(aflCio);
    }
}

단순한 제너릭 메서라면 이정도면 충분. 유연성을 더 높이려면 와일드카드 타입(item 31)을 사용한다.

추가로 다른 예제 항등함수를 보자. Function.identity를 (item 59) 사용하면 되지만 직접 만들어보자. 궁금 - 함등함수는 어디서 사용될까...? 항등함수는 잘 사용되는 편은 아니며 스트림의 map()으로 변환 작업할 때 변환 없이 그대로 처리할 때 사용된다.출처

UnaryOperator<String> uo = (x)->x.toUpperCase();
System.out.println(uo.apply("hello"));

public class GenericSingletonFactory {
    // 제너릭 싱글톤 팩토리 패턴
    // 항등함수 객체는 상태가 없으니 요청할때 마다 새로 생성하는 것은 낭비.
    // 자바 제너릭이 실체화된다면 항등함수를 타입별로 하나씩 만들어야 했겠지만,
    // 소거 방식을 사용한 덕에 제너릭 싱글톤 하나면 충분하다.
    private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;

    @SuppressWarnings("unchecked")
    public static <T> UnaryOperator<T> identityFunction() {
        // IDENTITY_FN을 UnaryOperator<T>로 형변환 하면  형변환 경고가 발생한다. 
        // 입력값을 수정없이 그대로 반환하는 함수이므로, 
        // T가 어떤 타입이든 UnaryOperator<T> 사용은 안전하다. 위 SuppressWarnings 추가
        return (UnaryOperator<T>) IDENTITY_FN; 
    }

    public static void main(String[] args) {
        String[] strings = { "jute", "hemp", "nylon" };
        UnaryOperator<String> sameString = identityFunction();
        for (String s : strings)
            System.out.println(sameString.apply(s)); // 형변환을 하지 않아도 오류 x, 경고 x

        Number[] numbers = { 1, 2.0, 3L };
        UnaryOperator<Number> sameNumber = identityFunction();
        for (Number n : numbers)
            System.out.println(sameNumber.apply(n));
    }
}

재귀적 타입 한정으로 타입 매개변수의 허용 범위를 한정할 수 있다. 주로 Comparable 과 함께 쓰인다.

최댓값 계산 RecursiveTypeBound 예.

// 재귀적 타입 한정으로 사용해서 상호 비교가능성을 표현한다. 
public class RecursiveTypeBound {
    // 최댓값 리턴 - recursive type bound 사용
    public static <E extends Comparable<E>> E max(Collection<E> c) {
        if (c.isEmpty())
            throw new IllegalArgumentException("Empty collection");

        E result = null;
        for (E e : c)
            if (result == null || e.compareTo(result) > 0)
                result = Objects.requireNonNull(e);

        return result;
    }

    public static void main(String[] args) {
        List<String> sl = Arrays.asList("a","b","c");
        System.out.println(max(sl));
    }
}

이 메서드에 빈 컬렉션을 건내면 IllegalArgumentException을 던지니, Optional를 반환하도록 고치는 편이 나을 것이다. item 55

이번 아이템에서 설명한 관용구, 여기에 와일드카드를 사용한 변형(item 31), 그리고 시뮬레이트한 셀프타입 관용구(item 2)를 이해하고 나면 실전에서 마주치는 대부분의 재귀적 타입한정을 잘 다루게 될 것이다.

제네릭 타입과 마찬가지로, 클라이언트에서 입력 매개변수와 반환값을 명시적으로 형변환해야 하는 메서드보다 제네릭 메서드가 더 안전하며 사용하기도 쉽다. (= 제네릭 메서드 사용하자) 기존 클라이언트는 그대로 둔 채 새로운 사용자의 삶을 훨씬 편하게 만들어줄 것이다

31

32 제네릭과 가변인수를 함께 쓸 때는 신중하라

• 가변인수(varargs)와 제네릭은 궁합이 좋지 않다. 가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하고, 배열과 제네릭의 타입 규칙이 서로 다르기 때문이다.

배열과 제네릭의 타입 규칙은 서로 다르다

• 배열은 공변 ( 상위 ( 부모 ) 타입으로 하위 ( 자식 ) 타입을 치환 할 수 있다 ) 이다. 제네릭은 불공변이다.

// 출처 https://yangbongsoo.gitbook.io/study/effective-java-3rd-edition/generics

// 실행 중에 문제를 일으킴
Object[] objectArray = new Long[1];
objectArray[0] = "hello"; // ArrayStoreException 예외 발생

// 컴파일 되지 않는 코드
List<Object> ol = new ArrayList<Long>(); //자료형 불일치
ol.add("hello");

• 매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다. 다른 타입 객체를 참조하는 상황에서 컴파일러가 자동 생성한 형변환이 실패하여, 제네릭 타입 시스템이 약속한 타입 안전성의 근간이 흔들릴 수 있다.

힙 오염(Heap Pollution)
힙 오염은 힙 메모리에 잘못된 데이터가 위치하는 것으로 추론할 수 있다.
Java 언어에서는 매개변수화된 타입의 변수가 매개변수 된 유형이 아닌 객체를 참조하는 경우 발생하는 상황이다.
출처: https://www.geeksforgeeks.org/what-is-heap-pollution-in-java-and-how-to-resolve-it/

• 아래 예시의 마지막 줄에 컴파일러가 생성한(보이지 않는) 형변환이 숨어 있어, 오류가 발생한다.

public class GenericAndVarargs {

    static void dangerous(List<String>... stringLists){
        List<Integer> intList = List.of(42);
        Object[] objects = stringLists;
        objects[0] = intList; //힙 오염 발생
        String s = stringLists[0].get(0); //ClassCastException
    }

}

가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하다

• 아래 예시는 배열의 참조를 노출하는 예시다. varargs 매개변수 배열을 그대로 반환하여, 힙 오염을 이 메서드를 호출한 쪽의 콜스택으로까지 전이하는 결과를 맞는다. toArray가 만드는 배열의 타입은 Object[]이다. pickTwo에 어떤 타입의 객체를 넘기더라도 담을 수 있는 가장 구체적인 타입이기 때문이다. 따라서 main에서 attributes에 값이 저장될 때 컴파일러가 ClassCastException을 던진다.

public class TypErrExam1 {

    //문제 발생 지점
    static <T> T[] toArray(T... args){
        return args;
    }

    //T 타입 인수 3개를 받아 그중 2개를 무작위로 골라 담은 배열을 반환
    static <T> T[]pickTwo (T a, T b, T c){
        switch(ThreadLocalRandom.current().nextInt(3)){
            case 0: return toArray(a,b);
            case 1: return toArray(a,c);
            case 2: return toArray(b,c);
        }
        throw  new AssertionError(); //도달할 수 없다.
    }

    public static void main(String[] args){
        String[] attributes = pickTwo("좋은", "빠른","저련함");
    }
}

그럼에도 제네릭 varargs 매개변수를 사용하는 이유

• 제네릭 varargs 매개변수는 타입 안전하지는 않지만, 실무에서 유용하기 때문에 허용된다.

ex)Arrays.asList(T... a), Collections.addAll(Collections<? super T> c, T... elements)

• 제네릭 varargs 매개변수를 타입 안전하게 사용하는 방법은 존재한다. 메서드가 배열에 아무것도 저장하지 않고, 그 배열의 참조가 밖으로 노출되지 않으면 된다. 즉, varargs 매개변수 배열이 호출자로부터 그 메서드로 순수하게 인수들을 전달한는 일만 한다면 안전하다.

• 하지만 메서드 선언시, 실체화 불가 타입으로 varargs 매개변수를 선언하면 컴파일러가 경고를 보내는 문제도 있다.

• 제네릭 가변인수 메서드의 호출자 쪽에서 발생하는 경고는 @SafeVarargs 애너테이션을 메서드에 달아 제거할 수 있다. 자바 7 전에는 사용자가 이 경고들을 그냥 두거나 호출하는 곳마다 @SuppressWarnings("unchecked") 애너테이션을 달아 경고를 숨겨야 했다.

-메서드에 제네릭 (혹은 매개변수화된) varargs 매개변수를 사용하고자 한다면, 먼저 그 메서드가 타입 안전한지 확인한 다음 @SafaVarargs 애너테이션을 달아 사용하는 데 불편함을 없애야 한다.

• 아래 코드는 임의 개수의 매개변수를 인수로 받아, 받은 순서대로 그 안의 모든 원소를 하나의 리스트의 옮겨 담아 반환하는 것으로 문제를 해결한다. 해당 메서드에 사용자를 헷갈리게 하는 컴파일 경고를 없애기 위해 @SafeVarargs를 달거나, varargs 매개변수를 List로 대체하자.

//toArray 대체 솔루션1
@SafeVarargs
static <T> List<T> flatten(List<? extends T>... lists){
    List<T> result = new ArrayList<>();
    for (List<? extends T> list : lists)
        result.addAll(list);
    return result;
}

//toArray 대체 솔루션2
static <T> List<T> flatten(List<List<? extends T>> lists){
    List<T> result = new ArrayList<>();
    for (List<? extends T> list : lists)
        result.addAll(list);
    return result;
}

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

• 컬렉션 API로 대표되는 일반적인 제네릭 형태에서는 한 컨테이너가 다룰 수 있는 타입 매개변수의 수가 고정되어 있다.

ex) Set<E>, Map<K,V>등의 컬렉션 

컨테이너(Container)

컴퓨터 과학에서 컨테이너란 클래스, 자료구조 또는 다른 객체들의 집합이 되는 인스턴스가 있는 추상 데이터 타입입니다. 다시 말해, 컨테이너는 특정 액세스 규칙을 따르는 체계적인 방식으로 객체들을 저장합니다. 출처: https://en.wikipedia.org/wiki/Container_(abstract_data_type)

• 하지만 더 유연한 수단이 필요할 때가 종종있다.

ex) 데이터베이스의 행이 임의의 개수의 열을 가지면서, 모든 열을 타입 안전하게 이용해야하는 상황 등

• 아래 코드 처럼 컨테이너 대신 키를 매개변수화한 다음, 컨테이너에 값을 넣거나 뺄 때 매개변수화한 키를 함께 제공하는 방식을 타입 안전 이종 컨테이너 패턴(type safe heterogeneous container pattern)이라 한다. 이 방식으로 제약을 해결할 수 있다.

ex) Map<K, V> 이 아닌 Map<Class<?>, Object>

• 아래 코드에서는 맵이 아니라 키가 와일드카드 타입이다. 이는 모든 키가 서로 다른 매개변수화 타입일 수 있다는 뜻이다. 첫 번째는 Class, 두 번째는 Class 식으로 될 수 있다. 다양한 타입을 지원하는 힘이 여기서 나온다.

// 타입별로 즐겨 찾는 인스턴스를 저장하고 검색할 수 있는 Favorites 클래스
public class Favorites {
    private Map<Class<?>, Object> favorites = new HashMap<>();

    public <T> void putFavorite (Class<T> type, T instance){
        favorites.put(Objects.requireNonNull(type), instance);
    }
    public <T> T getFavorite(Class<T> type){
        /* java.lang.Class.cast 메서드는
        *  하나의 객체를 어떤 클래스 또는 인터페이스로 캐스트하는 메서드이다.
        * 여기서는 Object인 favorites 맵의 값 타입을 T로 바꿔주는 역할을 한다.
        */

        return type.cast(favorites.get(type));
    }

    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());
    }

}

• putFavorite 는 주어진 Class 객체와 즐겨찾기 인스턴스를 favorites에 추가해 관계를 짓는다.

• getFavorite 는 cast 메서드를 통해 Class 객체가 알려주는 타입의 인스턴스인지 검사한 후, 맞다면 그 인수를 그대로 반환하고, 아니면 ClassCastException을 던진다.

• cast 메서드는 시그니처가 Class 클래스가 제네릭이라는 이점을 완벽히 활용한다. 다음 코드에서 보듯 cast의 반환 타입은 Class 객체의 타입 매개변수와 같다. 이것이 T로 비검사 형변환하는 손실 없이도 Favorites를 타입 안전하게 만드는 비결이다.

public class Class<T>{
    T cast(Object obj);
}

Favorites 클래스의 제약

첫번째, 악의적인 클라이언트가 Class 객체를 (제네릭이 아닌) 로 타입으로 넘기면 Favorites 인스턴스의 타입 안전성이 쉽게 깨진다. ex)아이템26 List<String> 형태가 아닌 List

• Favorites가 타입 불변식을 어기지 않도록 보장하려면, putFavorite 메서드에서 인수로 주어진 instance의 타입이 type으로 명시한 타입과 같은지 확인하자. 이를 위해 동적 형변환을 사용하면 된다.

• java.util.Collections에 checkedSet, checkedList, checkedMap 메서드가 이 방식을 적용한 예이다.

public <T> void putFavorite (Class<T> type, T instance){
    favorites.put(Objects.requireNonNull(type), type.cast(instance));
}

두 번째, 실체화 불가 타입에는 Favorites 클래스를 사용할 수 없다는 점이다.

ex) 아이템28 E, List<E>, List<String> .

List<String>.class와 List<Integer>.class는 List.class라는 같은 Class  객체를 공유하므로,
List<String>.class와 List<Integer>.class를  허용해서 둘 다 똑같은 타입의 객체 참조를 반환한다면,
Favorites 객체의 내부는 아수라장이 될 것이다.

• 두 번째 제약을 슈퍼타입토큰으로 어느정도 해결할 수 있다(완벽한 해결법은 없다). 타입 코드처럼 슈퍼 타입 토큰을 적용하면 제네릭 타입도 문제없이 저장할 수 있다.

컴파일타입 타입 정보와 런타임 타입 정보를 알아내기 위해 메서드들이 주고받는 class 리터럴을 타입 토큰이라 합니다.

슈퍼타입토큰 정리글 <br/>
http://gafter.blogspot.com/2006/12/super-type-tokens.html <br/>
https://yangbongsoo.gitbook.io/study/super_type_token

Favorites f = new Favorites();
List<String> pets = Arrays.asList("개", "고양이", "앵무");

f.putFavorite(new TypeRef<List<String>>(){}, pets);
List<String> listofStrings = f.getFavorite(new TypeRef<List<String>>(){});
TypeRef<List<String>>(){};

34 Enum

열거 타입은 일정 개수의 상수 값을 정의한 다음, 그 외의 값은 허용하지 않는 타입이다. 사계절, 태양계의 행성, 카드게임의 카드 종류 등이 좋은 예다. 자바에서 열거 타입을 지원하기 전에는 상수를 묶음으로 선언해서 사용하곤 했다.

정수 열거 패턴 - 안티패턴

public static final int APPLE_FUJ = 0;
public static final int APPLE_PIPPEN = 1;
public static final int APPLE_GRANNY_SMINTH = 2;

public static final int ORANGE_NAVEL = 0;
public static final int ORANGE_TEMPLE = 1;

정수 열거 패턴 기법에는 단점이 많다. 타입 안전을 보장할 방법이 없으며 표현력도 좋지 않다. 오렌지를 건네야 할 메서드에 사과를 보내고 동등 연산자(==)로 비교하더라도 컴파일러는 아무런 경고 메세지를 출력하지 않는다.

정수 열거 패턴을 사용한 프로그램은 깨지기 쉽다. 평범한 상수를 나영한 것뿐이라 컴파일하면 그 값이 클라이언트 파일에 그대로 새겨진다. 따라서 상수의 값이 바뀌면 클라이언트도 반드시 다시 컴파일해야한다.

다행히 자바는 열거 패턴의 단점을 말끔히 씻어주는 동시에 여러 장점을 안겨주는 대안을 제시했다. 바로 열거 타입(enum type)이다.

가장 단순한 열거 타입

public enum Apple { FUJI, PIPPIN, GRANNY_SMITH }
public enum ORANGE { NAVEL, TEMPLE, BLOOD }

겉보기에는 C, C++, C# 같은 다른 언어의 열거 타입과 비슷하지만, 보이는 것이 다가 아니다. 자바의 열거 타입은 완전한 형태의 클래스라서 (단순한 정숫값일 뿐인) 다른 언어의 열거 타입보다 훨씬 강력하다.

자바 열거 타입을 뒷받침하는 아이디어는 단순하다. 열거 타입 자체는 클래스이며, 상수 하나당 자신의 인스턴스를 하나씩 만들어 public static final 필드로 공개한다. 열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final이다. 따라서 클라이언트가 인스턴스를 직접 생성하거나 확장할 수 없으니 열거 타입 선언으로 만들어진 인스턴스들은 딱 하나씩만 존재함이 보장된다. 다시 말해 열거타입은 인스턴스 통제된다. 싱글턴은 원소가 하나뿐인 열거타입이라 할 수 있고, 거꾸로 열거 타입은 싱글턴을 일반화한 형태라고 볼 수 있다.

열거 타입은 정수 열거 패턴의 단점들을 해소해준다. 여기서 끝이 아니라 열거 타입에는 임의의 메서드나 필드를 추가할 수 있고, 임의의 인터페이스를 구현하게 할 수도 있다.

열거 타입에 메서드나 필드를 추가하기

어떨때 열거 타입에 메서드나 필드를 추가해야 할까? 각 상수에 연관된 데이터를 해당 상수 자체에 내재시키고 싶다고 해보자. Apple과 Orange를 예로 들면, 과일의 색을 알려주거나 과일 이미지를 반환하는 메서드를 ㅜ가하고 싶을 수 있다. 열거 타입에는 어떤 메서드도 추가할 수 있다.

태양계의 여덟 행성은 거대한 열거 타입을 설명하기에 좋은 예다. 각 행성에는 질량과 반지름이 있고, 이 두 속성을 이용해 표면 중력을 계산할 수 있다.

데이터와 메서드를 갖는 열거 타입

public enum Planet {
    MERCURY(3.302e+23, 2.439e6),
    VENUS (4.869e+24, 6.052e6),
    EARTH (5.975e+24, 6.378e6),
    MARS (6.419e+23, 3.393e6),
    JUPITER(1.899e+27, 7.149e7),
    SATURN (5.685e+26, 6.027e7),
    URANUS (8.683e+25, 2.556e7),
    NEPTUNE(1.024e+26, 2.477e7);

    private final double mass;              // 질량(단위: kg)
    private final double radius;            // 반지름(단위: m)
    private final double surfaceGravity;    // 표면중력(단위: m / s^2)

    // 중력상수(단위: m^3 / kg s^2)
    private static final double G = 6.67300E-11;

    // Constructor
    Planet(double mass, double radius) {
        this.mass = mass;
        this.radius = radius;
        surfaceGravity = G * mass / (radius * radius);
    }

    public double mass() { return mass; }
    public double radius() { return radius; }
    public double surfaceGravity() { return surfaceGravity; }
    /* 해당 행성에서의 무게를 구한다 */
    public double surfaceWeight(double mass) {
        return mass * surfaceGravity; // F = ma
    }
}

보다시피 거대한 열거 타입을 만드는 일도 그리 어렵지 않다. 열거 타입 상수 각각을 특정 데이터와 연결지으려면 생성자에서 데이터를 받아 인스턴스 필드에 저장하면 된다 열거 타입은 근본적으로 불변이라 모든 필드는 final이어야 한다.

값에 따라 분기하는 열거 타입

Planet 예에서 보여준 특성만으로 열거 타입을 사용하는 상황 대다수를 훌륭히 설명할 수 있다. 하지만 상수가 더 다양한 기능을 제공해 줬으면 할 때도 있다. 한 걸음 더 나아가 상수마다 동작이 달라져야 하는 상황도 있을 것이다. 예컨대 사칙연산 계산기의 연산 종류를 타입으로 선언하고, 실제 연산까지 열거 타입 상수가 직접 수행했으면 한다고 해보자. 먼저 switch문을 사용하는 방법이다.

값에 따라 분기하는 열거 타입

public enum Operation {
    PLUS, MINUS, TIMES, DIVIDE;

    // 상수가 뜻하는 연산을 수행한다
    public double apply(double x, double y) {
        switch (this) {
            case PLUS:
                return x + y;
            case MINUS:
                return x - y;
            case TIMES:
                return x * y;
            case DIVIDE:
                return x / y;
        }
        // 도달 불가능한 코드지만 아랫줄이 없으면 컴파일이 안된다
        throw new AssertionError("Unknown op: " + this);
    }
}

동작은 하지만 그리 예브지는 않다. throw 문에도 기술적으로 도달할 수 있고, 깨지기 쉬운 코드다. 예컨대 새로운 상수를 추가하면 해당 case 문도 추가 되어야 한다.

다행히 열거 타입은 상수별로 다르게 동작하는 코드를 구현하는 더 나은 수단을 제공한다. 열거 타입에 apply라는 추상 메서드를 선언하고 각 상수별 클래스 몸체, 즉 각 상수에서 자신에 맞게 재정의하는 방법이다. 이를 상수별 메서드 구현이라고 한다

상수별 메서드 구현을 활용한 열거 타입

public enum Operation {
    PLUS {
        public double apply(double x, double y) { return x + y; }
    },
    MINUS {
        public double apply(double x, double y) { return x - y; }
    },
    TIMES {
        public double apply(double x, double y) { return x * y; }
    },
    DIVIDE {
        public double apply(double x, double y) { return x / y; }
    };
    public abstract double apply(double x, double y);
}

보다시피 apply 메서드가 상수 선언 바로 옆에 붙어 있으니 새로운 상수를 추가할 때도 apply도 재정의 해야한다는 사실을 깜빡하기는 어려울 것이다. 그 뿐만 아니라 apply가 추상메서드 이므로 재정의 하지 않았다면 컴파일 오류로 알려준다.

상수별 메서드 구현을 상수별 데이터와 결합할 수도 있다. 다음은 Operation의 toString을 재정의해 해당 연산을 뜻하는 기호를 반환하도록 한 예다.

상수별 클래스 몸체(class body)와 데이터를 사용한 열거 타입

enum Operation {
    PLUS("+") {
        public double apply(double x, double y) { return x + y; }
    },
    MINUS("-") {
        public double apply(double x, double y) { return x - y; }
    },
    TIMES("*") {
        public double apply(double x, double y) { return x * y; }
    },
    DIVIDE("/") {
        public double apply(double x, double y) { return x / y; }
    };
    private final String symbol;
    Operation(String symbol) { this.symbol = symbol; }
    @Override public String toString() { return symbol; }
    public abstract double apply(double x, double y);
}

다음은 이 toString이 계산식 출력을 어마나 편하게 해주는지를 보여준다

  public static void main(String[] args) {
        double x = Double.parseDouble(args[0]);
        double y = Double.parseDouble(args[1]);
        for (OperationWithToString op : OperationWithToString.values()) {
            System.out.printf("%f %s %f = %f%n", x, op, y, op.apply(x, y));
        }
    }

열거 타입에는 상수 이름을 받아 그 이름에 해당하는 상수를 반환해주는 valueOf(String) 메서드가 자동 생성된다. 한편, 열거 타입의 toString 메서드를 재정의하려거든, toString이 반환하는 문자열을 해당 열거 타입 상수로 변환해주는 fromString 메서드도 함께 제공하는 걸 고려해보자.

열거 타입용 fromString 메서드 구현하기

private static final Map<String, OperationWithToString> stringToEnum =
            Stream.of(values()).collect(Collectors.toMap(Objects::toString, e -> e));
    
    public static Optional<OperationWithToString> fromString(String symbol){
        return Optional.ofNullable(stringToEnum.get(symbol));
    }

OperationWitToString 상수가 stringToEnum 맵에 추가되는 시점은 열거 타입 상수 생성 후 정적 필드가 초기화될 때다. 앞의 코드는 values 메서드가 반환하는 배열 대신 스트림을 사용했다.

fromString이 Optional을 반환하는 점도 주의하자. 이는 주어진 무자열이 가리키는 연산이 존재하지 않을 수 있음을 클라이언트에 알리고, 그 상황을 클라이언트에서 대처하도록 한 것이다.

상수별 메서드의 코드 공유

상수별 메서드 구현에는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다. 급여명세서에서 쓸 요일을 표현하는 열거 타입을 예로 생각해보자. 이 열거 타입은 직원의 (시간당) 기본 임금과 그날 일한 시간(분 단위)이 주어지면 일당을 계산해주는 메서드를 가지고 있다. 주중에 오버타임이 발생하면 잔업수당이 주어지고, 주말에는 무조건 잔업수당이 주어진다.

값에 따른 구현

package item34;

public enum PayrollDay {
    MONDAY,
    TUESDAY,
    WEDNESDAY,
    THURSDAY,
    FRIDAY,
    SATURDAY,
    SUNDAY;

    private static final int MINS_PER_SHIFT = 8 * 60;

    int pay(int minutesWorked, int payRate) {
        int basePay = minutesWorked * payRate;

        int overtimePay;
        switch(this) {
            case SATURDAY: case SUNDAY:
                overtimePay = basePay / 2;
                break;
            default:
                overtimePay = minutesWorked <= MINS_PER_SHIFT ? 0 : minutesWorked - MINS_PER_SHIFT) * payRate / 2;
        }

        return basePay + overtimePay;
    }
}

분명 간결하지만 관리 관점에서는 위험한 코드다. 휴가와 같은 새로운 값을 열거 타입에 추가하려면 그 값을 처리하는 case문을 잊지말고 쌍으로 넣어줘야 하는 것이다.

가장 깔끔한 방법은 새로운 상수를 추가할 때 잔업수당 '전략'을 선택하도록 하는 것이다. 다행히 멋진 방법이 있다. 잔업 수당 계산을 private 중첩 열거 타입으로 옮기고 PayrollDay열거 타입의 생성자에서 이중 적당한 것을 선택한다.

전략 열거 타입 패턴

enum PayrollDay {
    MONDAY(WEEKDAY), TUESDAY(WEEKDAY), WEDNESDAY(WEEKDAY),
    THURSDAY(WEEKDAY), FRIDAY(WEEKDAY),
    SATURDAY(WEEKEND), SUNDAY(WEEKEND);

    private final PayType payType;

    PayrollDay(PayType payType) { this.payType = payType; }

    int pay(int minutesWorked, int payRate) {
        return payType.pay(minutesWorked, payRate);
    }

    enum PayType {
        WEEKDAY {
            int overtimePay(int minsWorked, int payRate) {
                return minsWorked <= MINS_PER_SHIFT ? 0 :
                        (minsWorked - MINS_PER_SHIFT) * payRate / 2;
            }
        },
        WEEKEND {
            int overtimePay(int minsWorked, int payRate) {
                return minsWorked * payRate / 2;
            }
        };

        abstract int overtimePay(int mins, int payRate);
        private static final int MINS_PER_SHIFT = 8 * 60;

        int pay(int minsWorked, int payRate) {
            int basePay = minsWorked * payRate;
            return basePay + overtimePay(minsWorked, payRate);
        }
    }

    public static void main(String[] args) {
        for (PayrollDay day : values())
            System.out.printf("%-10s%d%n", day, day.pay(8 * 60, 1));
    }
}

보다시피 일반적으로 switch 문은 열거 타입의 상수별 동작을 구현하는 데 적합하지 않다.

열거 타입은 정수 상수보다 뛰어나다. 더 읽기 쉽고 안전하고 강력하다. 대다수 열거 타입이 명시적 생성자나 메서드 없이 쓰이지만, 각 상수를 특정 데이터와 연결짓거나 상수마다 다르게 동작하게 할 때는 필요하다. 드물게는 하나의 메서드가 상수별로 다르게 동작해야 할 때도 있다. 이런 열거 타입에서는 switch문 대신 상수별 메서드 구현을 사용하자. 열거 타입 상수 일부가 같은 동작을 공유한다면 전략 열거 타입 패턴을 사용하자

35 ordinal 메서드 대신 인스턴스 필드를 사용하라

• 모든 enum은 ordianl()이라는 메서드가 있음

public enum Ensemble {
     SOLO, DUET, TRIO, QUATET, QUINTET,
     SEXTET, SEPTET, OCTET, NONE, DECTET;
     
     // 절대 만들어서는 안되는 메소드, 타입을 추가하거나 제외할 경우에 매우 취약하다.
     //사람수를 얻는 함수 Bad_Ensemble.SOLO.numberOfMusicians() 호출시 1 return 됨
     public int numberOfMusicians() { return ordinal() + 1;} 
}

• 선언 순어가 바뀌면 오동작을 함 (SOLO가 DUET 뒤로 가버리면 2가 됨)

• ordinal()은 절대 두개 이상의 값을 가질 수 없음(8중주, 복4중주 구분 어려움)

• 더미상수를 집어넣어 코드가 더럽혀질 수 있음(12중주를 추가하고 싶은데, 11중주는 없으므로 의미없는 DUMMY를 넣어주게 된다면 코드가 더러워짐)

public enum Ensemble {

     DUET(2), SOLO(1), TRIO(3), QUARTET(4), QUINTET(5), SEXTET(6), SEPTET(7), OCTET(8), DOUBLE_QUARTET(8), NONET(9), DECTET(10), TRIPLE_QUARTET(12);
     
         public int numberOfMusicians() { return ordinal() + 1;} 
}

• ordinal() 함수 자체는 EnumSet EnumMap 처럼 일반적인 용도의 enum 기반 자료구조에서 사용할 목적으로 설계한 메서드 이다. 참조 : https://docs.oracle.com/javase/8/docs/api/java/lang/Enum.html

36 비트 필드 대신 EnumSet을 사용하라

• 열거 자료형 원소들을 집합에 사용할때 C 스타일로 int enum 패턴에 2의 거듭제곱 값을 대입해서 사용했음

public class Text{
     public static final int STYLE_BOLD = 1 << 0; //1
     public static final int STYLE_ITALIC = 1 << 1; // 2
     ...
     public void applyStyle(int styles){ ..}
}
text.appleStyles(STYLE_BOLD | STYLE_ITALIC); // 원소들을 집합으로 사용하기 위해서 | 비트 연산을 이용

• 상수 출력시 이해하기 어려움

  • STYLE_BOLD -> 1 출력

  • STYLE_BOLD | STYLE_ITALIC -> 3 출력

• 원소 순회 어려움

• 적절한 비트수(int나 long)를 줘야하고, API 수정 시 번거로움

• EnumSet을 대신 사용가능

  • 비트벡터로 구현 되어 있음 -> 원소가 64개 이하인 경우, EnumSet 전체를 long변수 하나로 표현

  • 비트 산술연산 가능

    • removeAll, retailAll 사용하여 대량작업 편리

public class Good_Text {
	public enum Style{
		BOLD, ITLIC, UNDERLINE, STRIKETHROUGH
	}
	
	public void applyStyles(Set<Style> styles) {
	}
}

사용예시

	EnumSet<Style> my_style = EnumSet.of(Style.BOLD, Style.ITLIC, Style.STRIKETHROUGH);
	System.out.println(my_style);

	my_style.removeAll(EnumSet.of(Style.BOLD, Style.ITLIC));
	System.out.println(my_style);

        //출력
        //[BOLD, ITLIC, STRIKETHROUGH]  
        //[STRIKETHROUGH]