정수 열거 패턴
열거 타입은 일정 개수의 상수 값을 정의한 다음, 그 외의 값은 허용하지 않는 타입이다.
정수 열거 패턴
package com.java.effective.item34;
public class Main {
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) 기법에는 단점이 많다.
정수 열거 패턴의 단점
1) 타입 안전을 보장할 수 없고 표현력도 좋지 않다.
2) 오렌지를 건네야할 메서드에 사과를 보낼 수 있다. (같은 int 타입이므로 컴파일 에러가 발생하지 않는다.)
3) 접두어를 명시해줘야 한다. 자바가 정수 열거 패턴을 위한 별도 이름공간을 지원하지 않기 때문에 접두어를 써서 이름 충돌을 방지한다.
4) 상수를 나열한 것뿐이라, 컴파일하면 그 값이 클라이언트 파일에 그대로 새겨진다. 상수의 값이 바뀌면 클라이언트도 반드시 다시 컴파일 해야한다.
5) 정수 상수는 문자열로 출력하기가 까다롭다. 그 값을 출력하거나 디버거로 살펴보면 단지 숫자로만 보인다.
6) 같은 정수 열거 그룹에 속한 모든 상수를 한바퀴 순회하는 방법도 마땅치 않다. 심지어 그 안에 상수가 몇개인지도 알 수 없다.
문자열 열거 패턴의 문제점
정수 대신 문자열 상수를 사용하는 변형 패턴도 있다. 상수 의미를 출력할 수 있다는 점은 좋지만, 경험이 부족한 프로그래머가 문자열 상수의 이름대신 문자열 값을 그대로 하드코딩하게 만든다. 이렇게 하드코딩한 문자열에 오타가 있어도 컴파일러는 확인할 수가 없으니 런타임 버그가 생겨, 더 나쁘다.
열거패턴의 등장
자바의 열거 타입이 등장했다. 열거 패턴의 단점을 덜어주고 많은 장점을 가지고있다. 자바의 열거 타입은 완전한 형태의 클래스라서 다른 언어의 열거 타입보다 훨씬 강력하다.
Apple.java
package com.java.effective.item34;
public enum Apple {
FUJI,
PIPPIN,
GRANNY_SMITH
}
Orange.java
package com.java.effective.item34;
public enum Orange {
NAVEL,
TEMPLE,
BLOOD
}
열거 타입 자체는 클래스이며, 상수 하나당 자신의 인스턴스를 하나씩 만들어 public static final 필드로 공개한다. 열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final 이다. 따라서 클라이언트가 인스턴스를 직접 생성하거나 확장할 수 없으니 열거 타입 선언으로 만들어진 인스턴스들은 딱 하나씩만 존재할 수 있다. 열거 타입 인스턴스는 통제된다. 우리가 알고있는 싱글톤은 원소가 하나뿐인 열거타입이라고 할 수 있고, 거꾸로 열거타입은 싱글톤을 일반화한 형태로 볼 수 있다.
열거타입의 장점
1) 열거타입은 컴파일 타임 타입 안전성을 제공한다.
Apple 열거 타입을 매개변수로 받는 메서드를 선언했다면, 건네받은 참조는 Apple의 세가지 값중 하나임이 확실하다. 다른 값을 넘기면 컴파일 오류가 발생한다.
2) 열거타입에는 각자의 이름 공간이 있다.
이름이 같은 상수도 평화롭게 공존할 수 있고, 열거 타입에 새로운 상수를 추가하거나 순서를 바꿔도 다시 컴파일하지 않아도 된다. 공개되는 것은 오직 필드의 이름 뿐이라, 상수 값이 클라이언트로 컴파일되어 각인되지 않기 때문이다.
3) 열거타입의 toString 메서드는 출력하기에 적합한 문자열을 내어준다.
4) 열거 타입에는 임의의 메서드나 필드를 추가할 수 있고, 임의의 인터페이스를 구현하게 할 수도 있다.
열거 타입에서 메서드 및 필드 추가 기능
위 Apple, Orange 클래스에서 과일의 색을 알려주거나 과일의 이미지를 반환하는 메서드를 추가하고 싶을 수도 있다. 이런 경우에 열거타입에는 어떤 메서드도 추가할 수 있다.
태양계의 여덟행성
package com.java.effective.item34;
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),
URAUS(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;
this.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
}
}
위 코드처럼 각 원하는 계산을 수행하는 메서드를 추가할 수 있다. private 필드의 접근자 메서드도 함께 제공했다.
위 코드의 생성자에서 표면중력을 계산하여 저장하고 있다. 이는 단순히 최적화를 위해서다. 질량과 반지름을 함께 받으므로 표면 중력은 언제든 계산할 수가 있다.
열거 타입을 만드는 일은 어렵지 않다. 열거 타입 상수 각각을 특정 데이터와 연결지으려면 생성자에 데이터를 받아 인스턴스 필드에 저장하면 된다. 열거 타입은 근본적으로 불변이라 모든 필드는 final 이여야 한다. 필드는 public 으로 선언해도 되지만, private 로 선언하고 별도로 public 접근자 메서드를 두는게 낫다.
for (Planet p : Planet.values()) {
....
}
열거 타입은 values 메서드를 제공한다.
* values 메서드
자신 안에 정의된 상수들의 값을 배열에 담아 반환하는 정적 메서드
출력결과
MERCURY
VENUS
EARTH
MARS
JUPITER
SATURN
URAUS
NEPTUNE
여기서, 명왕성이라는 행성을 제거해야한다. 우리는 이제 "열거 타입에서 상수를 하나 제거하면 어떻게 되지?"라는 의문이 생긴다. 이에 대한 대답은 "제거한 상수를 참조하지 않는 클라이언트에는 아무런 영향이 없다."이다. 만약 제거된 상수를 참조하는 클라이언트가 있다면, 컴파일시 오류가 발생하여 금방 발견할 수 있다.
열거타입 접근제한자
열거 타입을 선언한 클래스 혹은 그 패키지에서만 유용한 기능은 private, package-private 메서드로 구현한다. 이렇게 구현된 열거 타입 상수는 자신을 선언한 클래스 혹은 패키지에서만 사용할 수 있는 기능을 담게된다. 일반 클래스와 마찬가지로, 그 기능을 클라이언트에 노출할 필요가 없다면 private로 혹은 필요하다면 package-private 로 선언하자.
널리쓰이는 열거타입은 톱레벨 클래스로 만들고, 특정 톱레벨 클래스에서만 쓰인다면 해당 클래스의 멤버 클래스로 만든다.
상수의 더 다양한 기능 제공
package com.java.effective.item34;
public enum Operation {
PLUS,MINUS,TIMES,DIVDE;
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 DIVDE:
return x / y;
}
throw new AssertionError("알 수 없는 연산:" + this);
}
}
마지막의 throw문을 실제로 도달할 수 없지만, 기술적으로는 도달할 수 있기 때문에 생략하면 컴파일이 되지 않는다. 또한 위 코드는 깨지기 쉬운 코드로, 새로운 상수를 추가하면 case 문도 추가해야한다.
상수별 클래스 몸체(class body)와 데이터를 사용한 열거타입
package com.java.effective.item34;
public enum OperationEnum {
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;
}
},
DIVDE("/") {
public double apply(double x, double y) {
return x / y;
}
};
private final String symbol;
OperationEnum(String symbol) {
this.symbol = symbol;
}
@Override
public String toString() {
return symbol;
}
public abstract double apply(double x, double y);
}
위 코드의 경우, apply 메서드가 바로 옆에 붙어 있으니 새로운 상수가 추가될때 빼먹지 않을것이다. 또한 추상메서드이므로 재정의하지 않았다면 컴파일 오류가 발생하여 쉽게 오류를 발견할 수 있다.
열거 타입에는 상수 이름을 입력받아 그 이름에 해당하는 상수를 반환해주는 valueOf(String) 메서드가 자동 생성된다.
Operation.valueOf("PLUS").equals(Operation.PLUS); // true
fromString 메서드 제공
열거 타입의 toString 메서드를 재정의하려거든, toString 이 반환하는 문자열을 해당 열거 타입 상수로 변환해주는 fromString 메서드도 함께 제공하자.
private static final Map<String, Operation> stringToEnum =
Stream.of(Operation.values())
.collect(Collectors.toMap(Operation::toString, operation -> operation));
// 저장한 문자열에 해당하는 Operation 을 존재할 경우 반환한다.
public static Optional<Operation> fromString(String symbol) {
return Optional.ofNullable(stringToEnum.get(symbol));
}
Operation 상수가 stringToEnum 맵에 추가되는 시점은 열거 타입 상수 생성 후 정적 필드가 초기화될때다. 열거 타입 상수는 생성자에서 자신의 인스턴스를 맵에 추가할 수 없다. 열거 타입의 정적 필드 중 열거 타입의 생성자에서 접근할 수 있는 것은 상수 변수 뿐이다. 열거 타입 생성자가 실행되는 시점에는 정적 필드들이 아직 초기화되기 전이라, 자기 자신을 추가하지 못하게 하는 제약이 꼭 필요하다. 이 제약의 특수한 예로, 열거 타입 생성자에서 같은 열거 타입의 다른 상수에도 접근할 수 없다.
fromString 이 Optional<Operation> 반환 타입을 가지는데, 이는 주어진 문자열이 가리키는 연산이 존재하지 않을 수 있음을 클라이언트에 알리고, 해당 상황에 따라 클라이언트가 유연하게 대처하도록 한 것이다.
전략 열거 타입 패턴
상수별 메서드 구현에서는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다.
급여명세서에서 쓸 요일을 표현하는 열거 타입을 예로 생각해보자. 이 열거 타입은 직원의 시간당 기본 임금과 그날 일한 시간이 주어지면 일당을 계산해주는 메서드를 갖고있다. 주중에 오버타임이 발생하면 잔업수당이 주어지고, 주말에는 무조건 잔업수당이 주어진다. switch 문을 이용하면 case 문을 날짜별로 두어 이 계산을 쉽게 수행할 수 있다.
package com.java.effective.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 문의 추가가 필수적이다. 상수별 메서드 구현으로 급여를 정확히 계산하는 방법은 두가지다.
1) 잔업 수당을 계산하는 코드를 모든 상수에 중복해서 넣으면 된다.
2) 계산 코드를 평일용과 주말용으로 나눠 각각을 도우미 메서드로 작성한 다음 각 상수가 자신에게 필요한 메서드를 적절히 호출하면 된다.
위 두가지 방법 모두 가독성이 크게 떨어지고 오류 발생 가능성이 높아진다.
PayrollDay 에 평일 잔업수당 계산용 메서드인 overtimePay 를 구현하고, 주말 상수에서만 재정의해쓰면 장황한 부분을 줄일 수 있다. 하지만 이 방법도 새로운 상수를 추가하면 overtimePay 메서드를 재정의해야한다. 재정의하지 않으면 평일용 코드를 그대로 물려받는다.
가장 깔끔한 방법은 새로운 상수를 추가할때 잔업수당 '전략'을 선택하도록 하는 것이다. 잔업 수당 계산을 private 중첩 열거 타입으로 옮기고 PayrollDay 열거 타입의 생성자에서 이 중 적당한 것을 선택한다. 그러면 PayrollDay 열거 타입은 잔업수당 계산을 그 전략 열거 타입에 위임하여, switch 문이나 상수별 메서드 구현이 필요 없게 된다.
전략 열거 타입 패턴
package com.java.effective.item34;
public enum PayrollDay2 {
MONDAY(PayType.WEEKDAY),
TUESDAY(PayType.WEEKDAY),
WEDNESDAY(PayType.WEEKDAY),
THURSDAY(PayType.WEEKDAY),
FRIDAY(PayType.WEEKDAY),
SATURDAY(PayType.WEEKEND),
SUNDAY(PayType.WEEKEND);
private final PayType payType;
PayrollDay2(PayType payType) {
this.payType = payType;
}
int pay(int minutesWorked, int payRate) {
return payType.pay(minutesWorked,payRate);
}
/**
* 전략 열거 타입
*/
private enum PayType {
WEEKDAY { // 주일
int overtimePay(int minutesWorked, int payRate) {
return minutesWorked <= MINS_PER_SHIFT ?
0 : (minutesWorked - MINS_PER_SHIFT) * payRate / 2;
}
},
WEEKEND { // 주말
int overtimePay(int minutesWorked, int payRate) {
return minutesWorked * payRate / 2;
}
};
abstract int overtimePay(int minutesWorked, 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문이 좋은 선택이 될 수 있다.
public static Operation inverse(Operation operation) {
switch (operation) {
case PLUS:
return Operation.MINUS;
case MINUS:
return Operation.PLUS;
case TIMES:
return Operation.DIVDE;
case DIVDE:
return Operation.TIMES;
}
throw new AssertionError("알 수 없는 연산 : " +operation);
}
정리
열거 타입의 성능은 정수 상수와 별반 다르지 않다. 열거 타입은 필요한 원소를 컴파일 타임에 다 알 수 있는 상수 집합일 경우 사용하면 된다. 열거 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다. 열거타입은 나중에 상수가 추가되더라도 유연하게 처리가 가능해야한다. 열거 타입 상수 일부가 같은 동작을 공유한다면 전략 열거 타입 패턴을 사용하자.
'Book > Effective Java' 카테고리의 다른 글
[교재 EffectiveJava] 아이템 36. 비트 필드 대신 EnumSet을 사용하라 (0) | 2021.11.05 |
---|---|
[교재 EffectiveJava] 아이템 35. ordinal 메서드 대신 인스턴스 필드를 사용하라 (0) | 2021.11.05 |
[교재 EffectiveJava] 아이템 33. 타입 안전 이종 컨테이너를 고려하라 (0) | 2021.11.04 |
[교재 EffectiveJava] 아이템 32. 제네릭과 가변인수를 함께 쓸 때는 신중하라 (0) | 2021.11.03 |
[교재 EffectiveJava] 아이템 31. 한정적 와일드카드를 사용해 API 유연성을 높이라 (0) | 2021.11.02 |