1. 열거 타입

열거 타입은 일정 개수의 상수 값을 정의한 다음, 그 외의 값은 혀용하지 않는다. 열거 타입을 지원하기 전에는 아래 처럼 정수 상수를 한 묶음에 선언해서 사용했다.
1-1. 정수 열거 패턴
public static final int APPLE_FUJI = 0;
public static final int APPLE_PIPPIN = 1;
public static final int APPLE_SMITH = 2;
public static final int ORANGE_NAVEL = 0;
public static final int ORANGE_TEMPLE = 1;
public static final int ORANGE_BLOOD = 2;
많은 단점이 존재한다. 오렌지를 건네야 할 메서드에 사과를 건네도, 값은 같으니 의도된 바와 다르게 경고 메세지가 출력되지 않는다.이를 정수 열거 패턴이라고 부르는데, 이를 위한 별도 이름공간을 지원하지 않아 어쩔수 없이 APPLE, ORANGE 와 같이 접두어를 써서 이름 충돌을 방지할 수 밖에 없다. 또한, 그 값에 대한 문자열을 출력하기 까다롭다.
1-2. 문자열 열거 패턴
이는 정수 열거 패턴보다 더 나쁘다. 상수의 의미를 출력할 수는 있지만, 문자열 값을 그대로 하드코딩하게 되고 오타가 날 가능성을 배제할 수 없다. 런타임 버그가 생길 수 있고, 추후 문자열 비교에 따른 성능 저하도 불러올 수 있다.
public static final String PENDING = "PENDING";
public static final String IN_PROGRESS = "IN_PROGRESS";
public static final String COMPLETED = "COMPLETED";
public static final String FAILED = "FAILED";
1-3. 열거 타입
열거 패턴의 단점을 상쇄시켜줄 바로 열거 타입이 등장했다.
public enum Apople { FUJI, PIPPIN, GRANNY_SMITH }
public enum Orange { NAVEL, TEMPLE, BLOOD }
열거 타입 자체는 클래스이고, 상수 하나 당 자신의 인스턴스를 하나씩 만들어 public static final 필드로 공개한다. 열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않아 사실상 final 인 셈이다.
열거 타입은 컴파일타임 타입 안정성을 제공한다.
Applie 열거 타입을 매개변수로 받는 메서드가 있다면, 건네받는 참조는 Apple의 세 가지 값 중 하나임이 확실하고, 다른 타입의 값을 넘기려 한다면 컴파일 오류가 난다.
열거 타입은 각자의 이름 공간이 있어 이름이 같은 상수가 있을지라도 평화롭게 공존한다.
오직 공개되는 것은 필드의 이름뿐이라, 정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일되어 각인되지 않는다. 또한, 열거 타입의 toString 메서드는 출력하기에 적합한 문자열을 내준다.
열거 타입에는 임의의 메서드나 필드를 추가할 수 있고, 임의의 인터페이스를 구현할 수도 있다.
열거 타입에 메서드나 필드를 추가하는 것은 어떨 때 필요할까? Apple 로 예를 들면, 과일의 색을 알려주거나 이미지를 반환하는 메서드를 추가하고 싶을 수도 있다. 아래 태양계 에시를 자세히 살펴보자.
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
}
}
각 행성에는 질량과 반지름이 있고, 두 속성을 이용해 표면중력을 계산할 수 있다. 그리고, 열거 타입 상수 각각을 특정 데이터와 연결지으려면 생성자에서 데이터를 받아 인스턴스 필드에 저장하면 된다. 생성자에 로그를 찍으니, enum 객체 8개에 대한 루프를 도는 것이 확인되었다. 이제, 어떤 객체에서 지구의 무게를 입력받아 여덟 행성에서의 무게를 출력해보자.
// 어떤 객체의 지구에서의 무게를 입력받아 여덟 행성에서의 무게를 출력한다.
public class WeightTable {
public static void main(String[] args) {
double earthWeight = Double.parseDouble(args[0]);
double mass = earthWeight / Planet.EARTH.surfaceGravity();
for (Planet p : Planet.values())
System.out.printf("%s에서의 무게는 %f이다.%n",
p, p.surfaceWeight(mass));
}
}
MERCURY에서의 무게는 69.812739이다.
VENUS에서의 무게는 167.434436이다.
...
...
NEPTUNE에서의 무게는 210.208751이다.
열거 타입은 자신 안에 정의된 상수들의 값을 배열에 담아 반환하는 메서드인 values 를 제공한다. 또한, toString 을 재정의하지 않았을 때 상수 이름을 문자열로 반환하여 printf 로 출력하기에 안성맞춤이다. 그렇다면 만약 상수를 하나 제거했을 때, 제거한 상수를 참조하고 있는 곳에선 어떻게 될까? 다시 컴파일했을 때, 컴파일 오류가 발생한다.
그렇다면, 상수마다 동작이 달라져야 하는 사칙연산 계산기도 열거 타입으로 해결할 수 있을까?
연산 종류를 열거 타입으로 선언하고, 실제 연산까지 열거 타입 상수가 직접 하도록 만들어보자.
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);
}
}
Operation.PLUS.apply(1,2) // 3.0
새로운 상수가 추가되면, case 문을 추가해야하고, 깜빡한다면 새로운 연산을 수행하려할 때 "알 수 없는 연산" 런타임 오류가 날 것이다. 다행히, 아래와 같이 열거 타입은 더 나은 수단을 제공한다.
public enum OperationUpgrade {
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);
}
바로 추상메서드를 선언하고, 각 상수별 클래스 몸체제서 자신에 맞게 재정의 하는 방법이다. 이를 상수별 메서드 구현이라 한다. 바로 옆에 붙어있으니 재정의해야 한다는 사실을 까먹기도 힘들 것이다. 그리고, 재정의하지 않는다면 컴파일 오류로 알려준다. 한 단계만 더 나아가보자. Operation 의 toString 을 재정의해 해당 연산을 뜻하는 기호를 반환하도록 할 수 있다.
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 symbol; }
public abstract double apply(double x, double y);
}
public static void main(String[] args) {
double x = Double.parseDouble(args[0]);
double y = Double.parseDouble(args[1]);
for (Operation op : Operation.values())
System.out.printf("%f %s %f = %f%n",
x, op, y, op.apply(x,y));
}
2.00000 + 4.00000 = 6.000000
2.00000 + 4.00000 = 6.000000
2.00000 + 4.00000 = 6.000000
2.00000 + 4.00000 = 6.000000
toString 을 재정의함으로써 출력을 훨씬 편하게 나타낼 수 있다. 한편, 상수별로 메서드를 구현하는 것은 단점도 있다. 열거 타입 상수끼리 코드를 공유하기 어렵다는 점이다. 아래 급여명세서에서 쓸 요일을 표현하는 열거 타입을 살펴보자.
enum PayrolLDay {
MONDAY, TUESDAY, WEDSENDAY, THURSDAY, FRIDAY, SATURDAY, SUNDAY:
private static final int MINS_PER_SHIFT = 8 * 60;
int pay(int minutesWorked, int payRate) {
int basePay = minuitesWorked * payRate;
int overtimePay;
switch(this) {
case SATURDAY: case SUNDAY:
overtimePay = basePay /2;
break;
default:
overtimePay = minuutesWorked <= MINS_PER_SHIFT ? 0 : (minutesWorked - MINS_PER_SHIFT) * payRate / 2;
}
return basePay + overtimePay;
}
}
주말은 무조건 잔업수당이 주어지고, 주중에는 오버타임이 발생하면 잔업수당이 주어진다. 간결하지만, 위험한 코드이다. '휴가' 와 같은 새로운 값을 넣으려면, case 문 양쪽에 넣어줘야한다. 타파할 방법은, 새로운 상수를 추가할 때 잔업수당 '전략'을 선택하도록 하는 것이다. 다시 말해, 잔업 수당 계산을 중첩 열거 타입으로 옮기고, 톱레벨 열거 타입의 생성자에서 이 중 적당한 것을 선택하도록 하는 것이다.
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 문 대신 열거 타입을 생성자에서 선택하는 방식이다.
그러면 열거 타입을 과연 언제 쓰라는 것인가?
필요한 원소를 컴파일타임에 다 알 수 있는 상수 집합이라면 항상 열거 타입을 사용하자. 후에 상수가 추가되어도 상관없다. 열거타입은 나중에 상수가 추가되어도 바이너리 수준에서 호환되도록 설계되었기 때문에 컴파일을 다시 하지 않아도 반영된다.
'1️⃣ 백앤드 > 이펙티브 자바' 카테고리의 다른 글
| [아이템36] 비트 필드 대신 EnumSet 을 사용하라 (1) | 2024.11.04 |
|---|---|
| [아이템35] ordinal 메서드 대신 인스턴스 필드를 사용하라 (0) | 2024.10.31 |
| [아이템33] 타입 안전 이종 컨테이너를 고려하라 (0) | 2024.10.31 |
| [아이템32] 제네릭과 가변인수를 함께 쓸 때는 신중하라 (0) | 2024.10.30 |
| [아이템31] 한정적 와일드카드를 사용해 API 유연성을 높이라 (0) | 2024.10.28 |