2021-02-20 글
Enum ?
int Enum Pattern의 단점
타입 안전을 보장할 방법이 없다.
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;
위와 같은 예제에서는 사과용 상수 이름은 모두 APPLE_
로 시작,
오렌지용 상수는 ORANGE_
로 시작한다.
이는 표현력이 좋지 않다.
자바가 정수 열거 패턴을 위한 별도 이름 공간을 지원하지 않는다.
프로그램이 깨지기 쉽다.
평범한 상수를 나열한 것뿐이라 컴파일하면 그 값이 클라이언트 파일에 그대로 새겨진다.
상수의 값이 바뀌면 클라이언트도 반드시 다시 컴파일해야 한다.
문자열로 출력하기 까다롭다.
값을 출력하거나 디버거로 살펴보면 단지 숫자로만 보여서 썩 도움이 되지 않는다.
같은 정수 열거 그룹에 속한 모든 상수를 순회하는 방법도 마땅하지 않다.
또 이 안에 상수가 몇 개인지도 알 수 없다.
정수 대신 문자열 상수를 사용하는 변형 패턴은?
더 나쁘다.
상수의 의미를 출력할 수 있다는 점은 좋지만,
문자열 상수릐 이름 대신 문자열 값을 그대로 하드코딩하게 만들기 떄문이다.
문자열에 오타가 있어도 컴파일러는 확인할 길이 없으니 자연스럽게 런타임 버그가 생긴다.
또 문자열 비교는 비교적 성능 저하를 일으킨다.
열거 타입(Enum)
public enum Apple {FUJI, PIPPIN, GRANNY_SMITH}
public enum Orange {NAVEL, TEMPLE, BLOOD}
C, C++ 같은 다른 언어의 열거 타입과 다른 점은 자바의 열거 타입은 완전한 형태의 클래스다.
열거 타입 자체는 클래스며, 상수 하나당 자신의 인스턴스를 하나씩 만들어public static final
필드로 공개한다.
열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final이다.
따라서 클라이언트가 인스턴스를 직접 생성하거나 확장할 수 없으니 열거 타입 선언으로
만들어진 인스턴스들은 딱 하나씩만 존재함이 보장된다.
즉 열거 타입은 인스턴스 통제된다.
싱글턴은 원소가 하나뿐인 열거타입이라 할 수 있고,
열거 타입은 싱글턴을 일반화한 형태라고 볼 수 있다.
컴파일타임 타입 안정성 제공
public enum Apple {FUJI, PIPPIN, GRANNY_SMITH}
public enum Orange {NAVEL, TEMPLE, BLOOD}
위 코드에서 Apple의 열거 타입을 매개변수로 받는 메서드를 선언했다면,
건네받은 참조는 Apple의 세 가지 값 중 하나임이 확실하다.
다른 타입의 값을 넘기려 하면 컴파일 오류가 난다.
타입이 다른 열거 타입 변수에 할당하려 하거나
다른 열거 타입의 값 끼리 ==
연산자로 비교하려는 꼴이기 때문이다.
각자의 이름 공간이 존재한다.
때문에 이름이 같은 상수도 평화롭게 공존한다.
열거 타입에 새로운 상수를 추가하거나 순서를 바꿔도 다시 컴파일 하지 않아도 된다.
열거 타입에 새로운 상수를 추가하거나 순서를 바꿔도 다시 컴파일 하지 않아도 된다.
공개되는 것이 오직 필드의 이름뿐이니 ,
정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일 되어 각인되지 않기 때문이다.
문자열로 출력하기 적합하다.
열거타입의 toString()
은 출력하기에 적합한 문자열을 내어준다.
임의의 메서드, 필드를 추가하고 임의의 인터페이스를 구현할 수도 있다.
Object
메서드들을 높은 품질로 구현해놨고, Comparable
과 Serializable
을
구현했으며, 그 직렬화 형태도 웬만큼 변형을 가해도 문제없이 동작하게끔 구현해놨다.
열거 타입 사용 경우
각 상수와 연관된 데이터를 해당 상수 자체에 내재시킬 때
예제로 들었던 Apple과 Orange에 과일 색을 알려주거나,
과일 이미지를 반환하는 메서드를 추가한다면, 열거 타입에 이 기능을 메서드로 추가할 수 있다.
가장 단순하게는 그저 상수의 모음일 뿐인 열거 타입이지만,
고차원의 추상 개념 하나를 완벽히 표현해낼 수도 있다.
Example
태양개의 행성에는 각각 질량과 반지름이 있고, 이 두 속성을 이용해 표면중력을 계산할 수 있다.
따라서 어떤 객체의 질량이 주어지면 그 객체가 행성 표면에 있을 때의 무게도 계산할 수 있다.
표면 중력을 계산해 저장한 이유는 단순히 최적화를 위해서다.
@Getter
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.447e7);
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 surfaceWeight(double mass) {
return mass * surfaceGravity;
}
}
열거 타입 상수 각각을 특정 데이터와 연관지으려면 생성자에서 데이터를 받아 인스턴스 필드에 저장하면 된다.
열거 타입은 근본적으로 불변이라 모든 필드는 final이어야 한다.
필드를 public으로 선언해도 되지만 private로 두어 별도의 public 접근자 메서드를 두는게 낫다.
어떤 객체의 지구에서의 무게를 입력받아 행성에서의 무게를 출력하는 일을
다음같이 짧게 작성할 수도 있다.
public classs WeightTable {
public static void main(String[] args) {
double earthWeight = Double.parseDouble(args[0]);
double mass = earthWeight / Planet.EARTH.surfaceGravity();
for (Planet p : Palanet.values())
System.out.println("%s에서 무게는 %f이다. %n", p, p.surfaceWeight(mass));
}
}
지원하는 메서드
values()
: 자신 안에 정의된 상수들의 값을 배열에 담아 반환하는
정적 메서드, 값들은 선언된 순서로 저장valueOf()
: 상수 이름을 입력받아 그 이름에 해당하는 상수를 반환toString()
: 상수 이름을 문자열로 반환, 원하는 대로 재정의도 가능하다.fromString()
:toString
이 반환하는 문자열을 해당 열거 타입 상수로 변환
열거 타입에서 상수를 하나 제거하면?
제거한 상수를 참조하지 않는 클라이언트에는 아무 영향이 없다.
제거된 상수를 참조하는 클라이언트는 컴파일타임에 오류가 발생해 이를 잡을 수 있다.
상수마다 동작이 달라져야 할 경우
사칙연산 계산기의 연산 종류를 열거 타입으로 선언하고,
실제 연산까지 열거 타입 상수가 직접 수행하기로 한다.
public enum Operation {
PLUS, MINUS, TIMES, DIVIDE
}
switch
문으로 분기처리
/* 상수가 뜻하는 연산을 수행한다. */
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()
추상 메서드 선언
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()
가 추상 메서드이므로 재정의하지 않았다면 컴파일 오류로 알려준다.
상수별 클래스 몸체와 데이터를 사용
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);}
열거 타입용 fromString 메서드 구현
private static final Map<String, Operation> stringToEnum = Stream.of(values()).collect(toMap(Object::toString, e -> e));/* 지정한 문자열에 해당하는 Operation을 (존재한다면) 반환한다. */public static Optional<Operation> fromString(String symbol) { return Optional.ofNullable(stringToEnum.get(symbol));}
Operation 상수가 stringToEnum 맵에 추가되는 시점은
열거 타입 상수 생성 후 정적 필드가 초기화 될 때이다.
위 예제는 values 메서드가 반환하는 배열 대신 스트림을 사용했다.
열거 타입 상수는 생성자에서 자신의 인스턴스를 맵에 추가할 수 없다.
이렇게 하려면 컴파일 오류가 나는데, 이 방식이 허용된다면 런타임에 NullPointerException
이 발생했을 것이다.
열거 타입의 정적 필드 중 열거 타입의 생성자에서 접근할 수 있는 것은 상수 변수 뿐이다.
열거 타입 생성자가 실행되는 시점에는 정적 필드들이 아직 초기화되기 전이라,
자기 자신을 추가하지 못하게 하는 제약이 꼭 필요하다.
특수한 예로, 열거 타입 생성자에서 같은 열거 타입의 다른 상수에도 접근할 수 없다.
(열거 타입의 각 상수는 해당 열거 타입의 인스턴스를 public static final
필드로 선언했다.
즉, 다른 형제 상수도 static
이므로 열거 타입 생성자에서 정적 필드에 접근할 수 없다는 제약이 적용된다.)
또한, 위 예제에서 fromString
이 Optional<Operation>
을 반환하는 점도 주의하자.
주어진 문자열이 가리키는 연산이 존재하지 않을 수 있음을 클라이언트에 알리고,
그 상황을 클라이언트에서 대처하도록 한 것이다.
값에 따라 분기하여 코드를 공유하는 열거 타입 - 좋은 방법인가?
상수별 메서드 구현에는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다.
예시로 급여명세서에서 쓸 요일을 표현하는 열거 타입을 예로 생각해 보면,
직원의 기본 임금, 그날 일한 시간이 주어지면 일당을 계산해주는 메서드를 가지고 있다.
주중에 오버타임이 발생하면 잔업 수장이 주어지고, 주말에는 무조건 잔업 수당이 주어진다.switch
문을 이용하면 case 문을 날짜별로 두어 이 계산을 쉽게 수행할 수 있다.
enum PayrollDay { MONDAY, TUESDAY, WEDSDAY, 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
문을 잊지 말고 쌍으로 넣어줘야 한다.
PayrollDay에 평일 잔업수당 계산용 메서드인 overtimePay를 구현해놓고,
주말 상수에서만 재정의해 써도, 새로운 상수를 추가하면서 overtimePay 메서드를
재정의하지 않으면 평일용 코드를 그대로 물려받게 된다.
정략 열거 타입 패턴
새로운 상수를 추가할 때 잔업수당 '전략'을 선택하도록 하는 것이다.
잔업 수당 계산을 private 중첩 열거 타입(PayType)으로 옮기고,
PayrollDay 열거 타입의 생성자에서 이 중 적당한 것을 선택한다.
그러면 payrollDay 열거 타입은 잔업수당 계산을 그 전략 열거 타입에 위임하여,
switch 문이나 상수별 메서드 구현이 필요 없게 된다.
enum PayrollDay { MONDAY, TUESDAY, WEDSDAY, THURSDAY, FRIDAY, SATURDAY(PayTyoe.WEEKEND), SUNDAY(PayType.WEEKEND); private final PayType payType; PayrollDya(PayType payTyoe) {this.payType = payType;} int pay(int minutesWorked, int payRate) { return payType.pay(minutesWorked, payRate); } /* 전략 열거 타입 */ enum PayType { WEEKDAY { int overtimePay(int minusWorked, int payRate) { return minusWorked <= MINS_PER_SHIFT ? 0 : (minusWorked - MINS_PER_SHIFT) * payRate / 2; } }, WEEKEND { int overtimePay(int minusWorked, int payRate) { return minusWorked * 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); } }}
필요한 원소를 컴파일타임에 다 알 수 있는 상수 집합이라면, 항상 열거 타입을 사용하자
열거 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다.
열거 타입은 나중에 상수가 추가돼도 바이너리 수준에서 호환되도록 설계되었다.
정리
- 열거 타입은 정수 상수보다 읽기 쉽고, 안전하고 강력하다.
- 열거 타입은 명시적 생성자나 메서드 없이 쓰이지만, 각 상수를 특정 데이터와
연결짓거나 상수마다 다르게 동작하게 할 때 필요하다. - 드물게 하나의 메서드가 상수별로 다르게 동작해야 할 때도 있다.
이런 열거 타입에서는 switch 문 대신 상수별 메서드 구현을 사용한다. - 열거 타입 상수 일부가 같은 동작을 공유하면 전략 열거 타입 패턴을 사용하자.
'자바' 카테고리의 다른 글
📖 Exception에 대하여 (0) | 2021.08.02 |
---|---|
📖 Enum 열거형 (0) | 2021.08.02 |
[Effective java] item 28. 배열보다는 리스트를 사용하라 (0) | 2021.08.02 |
[Java] 불변 객체 (Immutable Class) (0) | 2021.08.02 |
[Java] String vs StringBuffer vs StringBuilder (0) | 2021.08.02 |