열거 타입은 일정 개수의 상수 값을 정의한 다음, 그 외의 값을 허용하지 않는 타입이다. 사계절, 태양계의 행성, 카도게임의 카드 종류 등이 좋은 예다. 자바에서 열거 타입을 지원하기 전에는 다음 코드처럼 정수 상수를 한 묶음으로 선언해서 사용하곤 했다.
public static final int APPLE_FUJI = 0;
public static final int APPLE_PIPPIN= 1;
public static final int ORANGE_NEVEL = 0;
public static final int ORANGE_TEMPLE = 1;정수 열거 패턴 기법에는 단점이 많다.
- 타입 안정을 보장할 방법이 없고 표현력도 좋지 않다.
- 접두어를 써서 이름 충돌을 방지해야 한다.
- 프로그램이 깨지기 쉽다.
컴파일하면 그 값이 클라이언트 파일에 그대로 새겨진다. 따라서 상수의 값이 바뀌면 클라이언트도 반드시 다시 컴파일해야 한다. 다시 컴파일하지 않은 클라이언트는 실행이 되더라도 엉뚱하게 동작한다. - 정수 상수는 문자열로 출력하기가 까다롭다. 그 값을 출력하거나 디버거로 살펴보면 단지 숫자로만 보여서 썩 도움이 되지 않는다.
정수 대신 문자열 상수를 사용하는 변형 패턴도 있다. 문자열 열거 패턴이라 하는 이 변형은 더 나쁘다.
- 상수의 의미를 출력할 수 있다는 점은 좋지만, 초보 프로그래머가 문자열 상수의 이름 대신 문자여 값을 그대로 하드코딩하게 만든다. 이렇게 하드 코딩한 문자열에 오타가 있어도 컴파일러는 확인할 방법이 없다. 그래서 런타임 버그가 생긴다. 문자열 비고에 따른 성능 저하도 발생한다.
이러한 열거 패턴의 단점을 해결하고 여러 장덤을 가진 열거 타입이라는 것이 있다. 예시 코드이다.
public enum Apple{FUJI, PIPPIN}
public enum Orange{NAVEL, TEMPLE}자바의 열거 타입은 완전한 형태의 클래스라서 다른 언어의 열거 타입보다 훨씬 강력하다.
자바 열거 타입 자체는 클래스이며, 상수 하나당 자신의 인스터스를 만들어 public static final 필드로 공개한다. 열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final이다. 따라서 클라이언트가 인스턴스를 직접 생성하거나 확장할 수 없으니 열거 타입 선언으로 만들어진 인스턴스들은 싱글톤이다.
열거 타입의 장점은 다음과 같다.
- 열거 타입은 컴파일탕미 타입 안전성을 제공한다.
Apple의 열거 타입을 매개변수로 받는 메서드를 선언했다면, 건네받은 참조는Apple의 세 가지 중 하나이다. 다른 타입의 값을 넘기려 하면 컴파일 오류가 난다. - 열거 타입에는 각자의 이름공간이 있어서 이름이 같은 상수도 평화롭게 공존한다.
- 열거 타입에 새로운 상수를 추가하거나 순서를 바뀌도 다시 컴파일하지 않아도 된다. 정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일되어 각인되지 않기 때문이다.
- 열거 타입의
toString메서드는 출력하기에 적합한 문자열을 반환한다.
또한 열거 타입에는 임의의 메서드나 필드를 추가할 수 있고 임의의 인터페이스를 구현하게 할 수도 있다. Objects 메서드들을 높은 품질로 구현해놨고, Comparable과 Serializable을 구현했으며, 그 직렬화 형태도 웬만큼 변형을 가해도 문제없이 동작하게끔 구현해놨다.
각 상수와 연관된 데이터를 해당 상수 자체에 내재시키고 싶을 때 열거 타입에 메서드나 필드를 추가하면 된다.
열거 타입은 상수별로 다르게 동작하는 코드를 구현하는 더 나은 수단을 제공한다. 열거 타입에 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);toString을 구현하면 매우 편리하다. 또한 toString이 반환하는 문자열을 해당 열거 타입 상수로 변환해주는 fromString 메서드도 함께 제공하는 걸 고려해보면 좋다.
(하나의 메서드가 상수별로 다르게 동작해야하는 경우)
한편, 상수별 메서드 구현에는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다. 급여명세서에는 쓸 요일을 표현하는 열거타입이 있다고 생각해보자. 요일별로 다르게 작동해야 할 경우 switch를 사용하면 된다. 하지만 관리 관점에서는 위험한 코드다. 휴가와 같은 새로운 값을 열거 타입에 추가하려면 그 값을 처리하는 case문을 잊지 말고 넣어줘야 한다. 상수별 메서드 구현을 가장 깔금하게 구현하는 방법은 새로운 상수를 추가할 때 전략을 선택하도록 하는 것이다. 잔업수당 계산을 private 중첩 열거 타입(예시 코드 PayType)으로 옮기고 PayrollDay 열거 타입의 생성자에서 이 중 적당한 것을 선택한다. 그러면 PayrollDay 열거 타입은 잔업수당 계산을 그 전략 열거 타입에 위임하여, switch문이나 상수별 메서드 구현이 필요없게 된다. 이 패턴은 switch문보다 복잡하지만 더 안전하고 유연하다.
enum PayrollDay{
MONDAY(WEEKDAY), TUESDAY(WEEKDAY), WENESDAY(WEEKDAY),
THURSDAY(WEEKDAY), FRIDAY(WEEKDAY),
SATURDAY(WEEKKEND), SUNDAY(WEEKKEND);
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)*payRated/2;
}
},
WEEKEND{
int overtimePay(int minsWorked, int payRate){
return minsWorked*payRated/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);
}
}
}(기존 열거 타입에 상수별 동작을 혼합하는 경우)
switch문을 열거 타입의 상수별 동작을 구현하는 데 적합하지 않다. 하지만 기존 열거 타입에 상수별 동작을 혼합해 넣을 때는 switch문이 좋은 선택이 될 수 있다.
pubic 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("Unknown op: " + op);
}
} 열거 타입은 언제 쓰면 될까? 필요한 원소를 컴파일타임에 다 알 수 있는 상수 집합이라면 항상 열거 타입을 사용하자. 또한 열거 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다. 열거 타입은 나중에 상수가 추가돼도 바이너리 수준에서 호환되도록 설계되었다.
