[EffectiveJava] item34 - int 상수 대신 열거 타입을 사용하라
01 May 2023열거 타입은 일정 개수의 상수 값을 정의한 다음, 그외의 값은 허용하지 않는 타입이다.
열거 타입(Enum Type)은 Java5 이후에 생긴 기능으로 그 이전에는 int나 String의 상수 값을 이용해 정수 열거 패턴을 구현했다.
public static final int APPLE_FUJI = 0;
public static final int APPLE_PIPPIN = 1;
public static final int APPLE_GRANNY_SMITH = 2;
public static final int ORANGE_NAVEL = 0;
public static final int ORANGE_TEMPLE = 1;
public static final int ORANGE_BLOOD = 2;
정수 열거 패턴(int enum pattern) 기법에는 단점이 많다.
타입 안전을 보장할 방법이 없으며 표현력도 좋지 않다. 오렌지를 건네야 할 메서드에 사과를 보낼 수도 있고, 동등 연산자(==)로 비교하더라도 컴파일러는 아무런 경고 메시지를 출력하지 않는다.
열거 타입 (Enum Type)
Java5 이후에 등장한 열거 타입은 이러한 단점을 말끔히 씻어주는 동시에 여러 장점을 안겨주었다.
아래의 코드는 열거 타입의 가장 단순한 형태다.
public enum Apple { FUJI, PIPPIN, GRANNY_SMITH }
public enum Orange { NAVEL, TEMPLE, BLOOD }
자바의 열거 타입은 완전한 형태의 클래스라서 다른 언어의 열거 타입보다 훨씬 강력하다.
열거 타입 자체는 클래스이며, 상수 하나당 자신의 인스턴스를 하나씩 만들어 public static final 필드로 공개한다.
열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final이다.
따라서 열거 타입 선언으로 만들어진 인스턴스들은 딱 하나씩만 존재함이 보장된다.
다시 말해 열거 타입은 인스턴스 통제가 되므로, 싱글톤은 원소가 하나뿐인 열거 타입이라 할 수 있고, 거꾸로 열거 타입은 싱글톤을 일반화한 형태라고 볼 수 있다.
열거 타입은 컴파일타임 타입 안정성을 제공한다. 위의 Apple 열거 타입을 매개변수로 받는 메서드를 선언했다면, 건네받은 참조는 (null이 아니라면) Apple의 세 가지 값 중 하나임이 확실하다.
다른 타입의 값을 넘기려고 하면 컴파일 오류가 난다.
열거 타입에는 각자의 이름공간이 있어서 이름이 같은 상수도 평화롭게 공존한다.
열거 타입에 새로운 상수를 추가하거나 순서를 바꿔도 다시 컴파일 하지 않아도 된다.
또한 열거타입은 임의의 메서드나 필드를 추가할 수 있고 임의의 인터페이스를 구현하게 할 수도 있다.
Object 메서드들을 높은 품질로 구현해놨고, Comparable과 Serializable을 구현했으며, 그 직렬화 형태도 웬만큼 변형을 가해도 문제없이 동작하게끔 구현해놨다.
열거 타입에 메서드나 필드를 추가한다는건 어떨때 필요한 기능일까?
아래 태양계에 대한 예시를 통해 알아보도록 하자.
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; /** 질량(단위: 킬로그램) */
private final double radius; /** 반지름(단위: 미터) */
private final double surfaceGravity; /** 표면중력(단위: m / s^2) */
/** 중력상수(단위: m^3 / kg s^2) */
private static final double G = 6.67300E-11;
/** 생성자 */
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이어야 한다.
필드는 public으로 선언해도 되지만, private으로 두고 별고의 public 접근자 메서드를 두는 게 낫다.
한편, Planet의 생성자에서 표면중력을 계산해 저장한 이유는 단순히 최적화를 위해서다.
질량과 반지름이 있으니 표면중력은 언제나 계산할 수 있기 때문이다.
Planet 열거 타입은 단순하지만 놀랍도록 강력하다. 어떤 객체의 지구에서의 무게를 입력받아 여덟행성에서의 무게를 출력하는 일을 다음처럼 짧은 코드로 작성할 수 있다.
@Test
void 행성_무게_출력_Test() {
double earthWeight = 60.0D;
double mass = earthWeight / Planet.EARTH.surfaceGravity();
for (Planet p : Planet.values())
System.out.printf("%s에서의 무게는 %f이다.%n", p, p.surfaceWeight(mass));
}
MERCURY에서의 무게는 22.674402이다.
VENUS에서의 무게는 54.303060이다.
EARTH에서의 무게는 60.000000이다.
MARS에서의 무게는 22.776240이다.
JUPITER에서의 무게는 151.780766이다.
SATURN에서의 무게는 63.930847이다.
URANUS에서의 무게는 54.291329이다.
NEPTUNE에서의 무게는 68.175811이다.
만약 태양계에서 명왕성처럼 또하나의 행성이 퇴출당해 열거 타입에서 상수를 또하나 제거해야 한다면 어떻게 될까?
열거 타입은 제거한 상수를 참조하지 않는 클라이언트에는 아무 영향이 없다.
행성_무게_출력_Test() 테스트 코드에서는 출력하는 줄 수가 하나 줄어들 뿐이다.
제거된 상수를 참조하는 클라이언트 같은 경우는 애플리케이션을 다시 컴파일 하면 제거된 상수를 참조하는 줄에서 유용한 메시지를 담은 컴파일 오류가 발생할 것이다.
정수 열거 패턴에서는 기대할 수 없는 바람직한 대응이라고 볼 수 있다.
열거 타입을 선언한 클래스 혹은 패키지에서만 유용한 기능은 private 나 package-private 메서드로 구현한다.
널리 쓰이는 열거 타입은 톱레벨 클래스로 만들고, 특정 톱레벨 클래스에서만 쓰인다면 해당 클레스의 멤버 클래스로 만든다.
열거 타입의 연산
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("알 수 없는 연산: " + this);
}
}
해당 코드는 제대로 동작하지만 우아한 코드가 아니다. 깨지기가 쉬운 코드이기 때문이다.
예컨데 새로운 상수를 추가하면 해당 case 문도 추가해야 한다. 혹시라도 깜빡한다면, 컴파일은 되지만 새로 추가한 연산을 수행하려 할때 “알 수 없는 연산” 이라는 런타임 오류를 내며 애플리케이션이 종료될 것이다.
그렇다면 어떻게 해야할까?
열거 타입은 상수별로 다르게 동작하는 코드를 구현하는 더 나은 수단을 제공한다.
열거 타입에 apply라는 추상 메서드를 선언하고 각 상수별 클래스 몸체(constant-specific class body), 즉, 상수에서 자신에 맞게 재정의 하는 방법이다.
이를 상수별 메서드 구현(constant-specific method implementation)이라 한다.
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가 추상 메서드이므로 재정의하지 않았다면 컴파일 오류로 알려준다.
더나아가 상수별 메서드 구현을 상수별 데이터와 결합할 수도 있다.
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; }
@Override public String toString() { return this.symbol; }
public abstract double apply(double x, double y);
}
위의 코드 같이 구현된다면 toString 이 계산식 출력을 얼마나 편하게 해주는지 볼 수 있다.
@Test
void 연산_Test() {
double x = 3.55D;
double y = 71.13D;
for (Operation op : Operation.values())
System.out.printf("%f %s %f = %f%n", x, op, y, op.apply(x, y));
}
3.550000 + 71.130000 = 74.680000
3.550000 - 71.130000 = -67.580000
3.550000 * 71.130000 = 252.511500
3.550000 / 71.130000 = 0.049909
열거 타입 응용
열거 타입에는 상수 이름을 입력받아 그이름에 해당하는 상수를 반환해주는 valueOf(String) 메서드가 자동 생성된다.
또한, 열거 타입의 toString 메서드를 재정의하려거든, toString이 반환하는 문자열을 해당 열거 타입 상수로 변환해주는 fromString 메서드도 함께 제공하는걸 고려해보자.
private static final Map<String, Operation> stringToEnum = Stream.of(values()).collect(toMap(Objects::toString, e -> e));
/** 지정한 문자열에 해당하는 Operation을 (존재한다면) 반환한다. */
public static Optional<Operation> fromString(String symbol) {
return Optional.ofNullable(stringToEnum.get(symbol));
}
Operation 상수가 stringToEnum 맵에 추가되는 시점은 열거 타입 상수 생성 후 정적 필드가 초기화 될 때이다.
fromString이 Optional<Operation>을 반환하는 점도 주의하자. 이는 주어진 문자열이 가리키는 연산이 존재하지 않을 수 있음을 클라이언트에 알리고 그 상황을 클라이언트에서 대처하도록 ㅏㄴ것이다.
전략 열거 타입 패턴
한편, 상수별 메서드 구현에는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다.
급여명세서에서 쓸 요일을 표현하는 열거 타입을 예로 생각해보자.
이 열거타입은 직원의 (시간당) 기본 임금과 그날 일한 시간(분단위)이 주어지면 일당을 계산해주는 메서드를 갖고있다.
만약 주중에 오버타임이 발생하면 잔업수당이 주어지고, 주말에는 무조건 잔업수당이 주어진다.
상수 월~금까지가 동일한 로직, 토~일이 동일한 로직으로 두가지 패턴을 각 상수에 중복되게 들어가는 것이다.
해당 로직을 switch문으로 작성하면 다음과 같다.
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, SUNDAY -> {
overtimePay = basePay / 2;
break;
}
/** 주중 */
default -> overtimePay = minutesWorked <= MINS_PER_SHIFT ?
0 : (minutesWorked - MINS_PER_SHIFT) * payRate / 2;
}
return basePay + overtimePay;
}
}
분명 간결하지만, 관리 관점에서는 위험한 코드다.
휴가와 같은 새로운 값을 열거 타입에 추가하려면 그 값을 처리하는 case 문을 잊지말고 쌍으로 넣어줘야한다.
자칫 로직을 추가하지 않는다면 휴가기간에 일을 하더라도, 주중에 일한것과 동일한 로직을 타게 될것이다.
이러한 단점을 개선하기 위해 전략 열거 타입 패턴을 사용할 수 있다.
상수가 추가될때마다 잔업수당에 대한 ‘전략’을 선택하도록 하는것이다.
잔업수당 계산을 private 중첩 열거 타입(enum PayType)으로 옮기고, PayrollDay 열거 타입의 생성자에서 이중 적당한 로직을 선택하여 계산하는 것이다.
그러면 PayrollDay 열거 타입은 잔업수당 계산을 그 전략 열거 타입에 위임하여, switch 문이나 상수별 메서드 구현이 필요 없게 된다.
public 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 minutesWorked, int payRate) {
int basePay = minutesWorked * payRate;
return basePay + overtimePay(minutesWorked, payRate);
}
}
}
열거 타입의 switch문
그렇다고 switch문이 열거타입에서 아예 적합하지 않다는 뜻은 아니다.
기존 열거 타입에 상수별 동작을 혼합해 넣을 때는 switch문이 좋은 선택이 될 수 있다.
다음과 같은 예시에서 쓰인다.
public static Operation inverse(Operation op) {
switch (op) {
case PLUS -> { return Operation.MINUS; }
case MINUS -> { return Operation.PLUS; }
case TIMES -> { return Operation.DIVIDE; }
case DIVIDE -> { return Operation.TIMES; }
default -> throw new AssertionError("알 수 없는 연산: " + op);
}
}
결론
열거 타입은 필요한 원소를 컴파일타임에 다 알 수 있는 상수 집합이라면 항상 열거 타입을 사용하자.
또한 열거 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다. 열거타입은 나중에 상수가 추가돼도 바이너리 수준에서 호환되도록 설계되었다.