SUMFIのBlog HomeArchivesTagsCategoriesAbout
[Effective Java] int 상수 대신 열거 타입을 사용하라
|LanguagesJavaEffective Java
Word count: 1.5k|Reading time: 9 min

들어가며

정수 열거 패턴(int enum pattern)에는 단점이 많다. 타입 안전을 보장할 방법이 없으며 포현력도 좋지 않다. 오렌지를 건네야 할 메서드에 사과를 보내고 동등 연산자(==)로 비교하더라도 컴파일러는 아무런 경고 메세지를 출력하지 않는다. 깨지기 쉬운 프로그램을 만드는 방법이며 정수 상수는 문자열로 출력하기도 리플렉션을 이용하면 되지만 방법이 까다롭다.

문자열 열거 패턴(string enum pattern)은 더 나쁘다. 상수의 의미를 출력할 수 있음은 좋지만, 문자열 상수의 이름 대신 문자열 값을 그대로 하드코딩 하는 방식이다. 하드코딩한 문자열에 오타가 있어도 컴파일러는 알 방도가 없으며 문자열 비교에 따른 성능 저하는 덤이다.

Enum

자바의 enum은 C, C++의 enum보다 강력하다. enum의 바탕이 되는 아이디어는 단순하다. enum 자체는 하나의 클래스이며 상수 하나당 자신의 인스턴스를 하나씩 만들어 public static final 필드로 공개한다. enum은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final이다. 따라서 클라이언트가 인스턴스들을 딱 하나만 생성할 수 있도록 통제할 수 있음이 보장된다. 즉, enum은 싱글톤이다.

enum은 컴파일타임 타입 안전성을 제공한다. 어느 enum 클래스를 매개변수로 받는 메소드를 선언했다면 건네 받은 참조는 null 아니면 enum 클래스 내의 인스턴스뿐이다. 다른 타입의 enum 클래스를 넘기면 컴파일 오류가 난다. 타입이 다른 enum 변수에 할당하려 하거나 다른 enum 타입끼리 동등 연산을 하기 때문이다.

enum 클래스 각각은 고유한 namespace가 있어서 이름이 같은 상수도 공존할 수 있다. 또한 enum에 새로운 상수를 추가하거나 순서를 바꾸어도 클라이언트 사이드를 다시 컴파일하지 않아도 된다. 공개되는 것이 오직 필드의 이름뿐이라 정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일되어 각인되지 않기 때문이다. 다음 코드는 동작할 것 같으나 컴파일이 불가능한 코드이다. 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public enum ProductEnum {
    TV(TV.class),
    REFRIGERATOR(Refrigerator.class);

    private final Class clazz;

    ProductEnum(Class clazz) {
        this.clazz = clazz;
    }

    public Class getProductClass() {
        return clazz;
    }
}

public List<Refrigerator> getOverStorageFridge(int storage) throws ProductNotFoundException {
    List<Refrigerator> result = getProducts(ProductEnum.REFRIGERATOR.getProductClass()).stream().filter(refrigerator -> refrigerator.getStorage() >= storage).collect(Collectors.toList());
    isProductExists(result);
    return result;
}

다음과 같이 바꾼다면 컴파일이 가능하며 정상 동작한다. 위의 코드가 불가능한 이유는 상수 값이 클라이언트로 컴파일되어 각인되지 않기 때문이다.

1
2
3
4
5
public List<Refrigerator> getOverStorageFridge(int storage) throws ProductNotFoundException {
    List<Refrigerator> result = getProducts(Refrigerator.class).stream().filter(refrigerator -> refrigerator.getStorage() >= storage).collect(Collectors.toList());
    isProductExists(result);
    return result;
}

또한 enum의 toString 메소드는 출력하기 적합한 문자열을 리턴한다. 이 뿐만 아니라 enum에는 임의의 메소드나 필드를 추가할 수 있고 임의의 인터페이스를 구현하게 할 수도 있다. 다음은 enum에 필드와 메소드를 추가한 간단한 코드이다.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public enum Lotto {
    FIRST(10000000, "1등"),
    SECOND(5000000, "2등"),
    THIRD(300000, "3등"),
    FOURTH(20000, "4등"),
    FIFTH(1000, "5등");

    private int reward;
    private String rank;

    Lotto(int reward, String rank) {
        this.reward = reward;
        this.rank = rank;
    }

    public int getReward() {
        return reward;
    }

    public String getRank() {
        return rank;
    }
}

기능이 들어있는 enum 클래스를 만드는 일도 어렵지 않다. enum 상수 각각을 특정 데이터와 연결 지으려면 생성자에서 데이터를 받아 인스턴스 필드에 저장하면 된다. enum은 근본적으로 불변이라 모든 필드는 final이여야 한다. enum은 자신 안에 정의된 상수들의 값을 배열에 담아 리턴하는 정적 메소드인 values를 제공한다. 각 enum의 값의 toString은 상수 이름을 문자열로 반환한다. 마음에 들지 않는다면 오버라이딩을 통해 재정의도 가능하다.

그렇다면 enum의 상수 하나를 제거하면 어떻게 될까? 이는 제거한 상수를 참조하지 않는 클라이언트는 아무 영향이 없다. 참조하는 클라이언트라면 재 컴파일시에는 상수를 참조하는 코드라인에서, 재 컴파일을 하지 않았다면 런타임에 해당 코드라인에서 오류가 발생한다. 아주 바람직하다.

enum을 외부 클라이언트에 노출할 필요가 없다면 private나 package-private로 선언하면 된다.

종종 상황에 따라 enum의 상수마다 동작이 달리지는 코드가 필요해질 경우가 있다. 다음 코드를 보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
enum TrafficLightColour { RED, GREEN, YELLOW }

void approachIntersection(TrafficLightColour state) {
  boolean stop;
  switch (state) {
    case GREEN:
      stop = false;
      break;
    case YELLOW:
    case RED:
      stop = true;
      break;
  }
  if (stop) {
    ...
  }
}

위 코드는 동작은 하지만 깔끔하지 못하다. stop의 코드라인은 stop에 정상적인 값이 할당 되어야만 도달할 수 있을거 같지만 초기화 되지 않은 상태로도 도달이 가능하다. 위에 말한 컴파일 상황을 이용하는 것이다.

The definition of control flow in JLS §14.21 does not consider whether enum switches handle all cases, so in the example above javac will complain that stop is not definitely assigned. This is because adding constants to an enum is a binary compatible change (see JLS §13.4.26), so the spec allows for the possibility that TrafficLightColour is defined in another library, and after compiling our code we update to a new version of the library (without recompiling) that adds another colour of traffic light (say, PURPLE) that the switch doesn’t handle.

This check should be used together with MissingCasesInEnumSwitch in environments where that kind of binary incompatibility is very unlikely. For example, if your build system accurately tracks changes to dependencies and you are deploying an application (instead of a library), the risk of skew between compile-time and runtime is minimal. One the other hand, if you are a library author and your code switches on an enum in a different library, you want want to include ‘defensive’ default cases to handle the situation where a user deploys your code together with an incompatible version of the other library.

더 안좋은 점은 깨지기 쉬운 코드라는 점이다. 새로운 상수를 추가할 때 마다 case를 정의해주어야 한다. 다행히 enum은 상수별로 다르게 동작하는 코드를 더 나은 수단으로 제공한다. 또한 toString을 재정의하려거든 toString이 반환하는 문자열을 해당 enum 타입 상수로 변환해주는 메소드도 구현할 수 있다. 다음 코드를 보자.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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;}};

    private final String symbol;

    Operation(String symbol) { this.symbol = symbol; }


    public abstract double apply(double x, double y);

    @Override
    public String toString() {
        return symbol;
    }

    private static final Map<String, Operation> stringToEnum = Stream.of(values()).collect(Collectors.toMap(Object::toString, e -> e));

    public static Optional<Operation> fromString(String symbol) {
        return Optional.ofNullable(stringToEnum.get(symbol));
    }
}

Operation 상수가 stringToEnum 맵에 추가되는 시점은 enum 타입 상수 생성 후 정적 필드가 초기화 될 때다. 앞의 코드는 스트림을 이용했다. 자바 8 이전에는 빈 해시맵을 만들고 values가 반환한 배열을 순회하며 map에 값을 추가했을 것이다. 하지만 enum 타입 상수는 생성자에서 자신의 인스턴스를 맵에 추가할 수 없다. 이렇게 하려면 컴파일 오류가 나는데 만약 이 방식이 허용되었다면 런타임에 NullPointerException이 발생했을 것이다. enum 타입의 정적 필드 중 enum 타입의 생성자에서 접근할 수 있는 것은 상수 변수뿐이다. enum 타입 생성자가 실행되는 시점에는 정적 필드들이 아직 초기화되기 전이라 자기 자신을 추가하지 못하게 하는 제약이 꼭 필요하다. 이 제약의 특수한 예로 enum 타입 생성자에서 같은 enum 타입의 다른 상수에도 접근할 수 없다. fromString이 Optional을 반환하는 점도 주의하자. 이는 주어진 문자열이 가리키는 연산이 존재하지 않을 수 있음을 클라이언트에 알리고 그 상황을 클라이언트에서 대처하도록 한 것이다.

하지만 상수별 메소드 구현에는 enum 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다. 다음 코드를 보자.

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

간결하지만 이 또한 깨지기 쉬운 코드다. 다음 두 방법을 생각해보자. 첫번째는 상수별로 중복해서 잔업수당을 계산하는 코드를 넣는 방법이다. 두번째는 평일용과 주말용 계산 메소드를 helper 메소드로 작성한 다음 각 상수가 자신에게 필요한 메소드를 적절히 호출하면 된다. 두 방식 모두 가독성이 떨어진다. 또 switch문과 같은 단점이 발생한다. 가장 깔끔한 방법은 전략 패턴을 적용한 방법이다. 다음 코드를 보자.

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
32
33
34
35
36
37
38
39
40
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문이 반드시 부적합한것은 아니다. 기존 enum 타입에 상수별 동작을 혼합해 넣을 때는 switch문이 좋은 선택이 될 수도 있다. 예를 들어 서드파티에서 가져온 Operation enum 타입을 통해 각 연산의 반대 연산을 반환하는 메소드를 작성할 때는 적합할 수 있다. 혹은 추가하려는 메소드가 의미상 enum 타입에 속하지 않을때도 적합하다.

enum의 성능은 정수 상수와 크게 다르지 않다. 그럼 enum은 언제 써야할까? enum 타입은 필요한 원소를 컴파일 타임에 다 알 수 있는 상수 집합이라면 항상 enum 타입을 사용하자. 메뉴 아이템, 연산 코드, 플레그 등이 모두 여기 포함된다. 또한 enum 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다. 나중에 추가되도 바이너리 수준에서 호환이 가능하도록 설계되었기 때문이다.

Author: Song Hayoung
Link: https://songhayoung.github.io/2020/08/12/Languages/Effective%20JAVA/item34/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.
JAVA