자바에서의 열거 타입이 없었다면?
아래처럼 정수 상수를 한 묶음으로 선언해서 사용하곤 했다.
1
2
3
4
5
6
7
8
// 코드 34-1 정수 열거 패턴 - 상당히 취약하다!
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;
위와 같은 정수 열거 패턴은 단점이 많다.
- 1)타입 안전을 보장할 방법이 없으며 표현력도 좋지 않다.
- 오렌지를 건네야할 메서드에 사과를 보내도 동등 연산자(==)로 비교하더라도 컴파일러는 아무런 경고 메시지를 출력하지 않는다.
- 2)프로그램이 깨지기 쉽다.
- 평범한 상수를 나열한 것뿐이라 컴파일하면 그 값이 클라이언트 파일에 그대로 새겨진다. 따라서 상수의 값이 바뀌면 클라이언트도 반드시 다시 컴파일 해야 한다. 그렇지 않으면 프로그램은 깨질 것이다.
- 3)같은 정수 열거 그룹에 속한 모든 상수를 한 바퀴 순회하는 방법도 마땅치 않고 그 안에 몇 개의 상수가 존재하는지 알 수 가 없다.
- enum의 경우 values() 메서드 호출 후 length 메서드를 호출하면 쉽게 알 수 있다.
자바의 열거 타입 Enum
자바의 열거 타입은 완전한 형태의 클래스라서 (단순한 정숫값일 뿐인) 다른 언어의 열거 타입보다 훨씬 강력하다.
- 열거 타입 자체는 클래스이며, 상수 하나당 자신의 인스턴스를 하나씩 만들어
public static final필드로 공개한다. - 열거 타입은 밖에서 접근할 수 있는 생성자를 제공하지 않으므로 사실상 final 이다.
- 따라서 클라이언트가 인스턴스를 직접 생성하거나 확장할 수 없으니 열거 타입 선언으로 만들어진 인스턴스들은 딱 하나씩만 존재함이 보장된다.
- 다시 말해 열거 타입은 인스턴스 통제된다(9쪽).
- 싱글턴(아이템3)은 원소가 하나뿐인 열거 타입이라 할 수 있고, 거꾸로 열거 타입은 싱글턴을 일반화한 형태라 볼 수 있다.
- 열거 타입은 컴파일타임 안정성을 제공한다.
- 열거 타입에는 각자의 이름공간이 있어서 이름이 같은 상수도 평화롭게 공존한다.
- 열거 타입에 새로운 상수를 추가하거나 순서를 바꿔도, 다시 컴파일하지 않아도 된다. 공개되는 것이 오직 필드의 이름뿐이라, 정수 열거 패턴과 달리 상수 값이 클라이언트로 컴파일되어 각인 되지 않기 때문이다.
- ‘상수 값이 클라이언트로 컴파일되어 각인 되지 않는다’ 는 부분이 쉽게 이해되지 않는다..
- 마지막으로, 열거 타입의 toString 메서드로 출력하기에 적합한 문자열을 내어준다.
- 오버라이드 하지 않을 경우 아래 처럼 그냥 단순하게 name() 값이 출력된다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public enum PayType {
SAMSUNG("삼성페이"),
APPLE("애플페이");
private final String label;
PayType(String label) {
this.label = label;
}
}
public class TestMain {
public static void main(String[] args) {
System.out.println(PayType.SAMSUNG);
System.out.println(PayType.APPLE);
}
}
public class TestMail{
public static void main(String[] args) {
System.out.println(PayType.SAMSUNG);
System.out.println(PayType.APPLE);
}
}
// SAMSUNG
// APPLE
이처럼 열거 타입은 정수 열거 패턴의 단점들을 해소해준다. 여기서 끝이 아니라 열거 타입에 임의의 메서드나 필드를 추가할 수 있고 임의의 인터페이스를 구현하게 할 수도 있다.
Object 메서드들(3장)을 높은 품질로 구현해놨고, Comparable(아이템14)과 Serializable(12장)을 구현했으며, 그 직렬화 형태도 웬만큼 변형을 가해도 문제없이 동작하게끔 구현해놨다.
데이터와 메서드를 갖는 열거 타입
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
// 코드 34-3 데이터와 메서드를 갖는 열거 타입 (211쪽)
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 이어야 한다(아이템17) 필드를 public으로 선언해도 되지만, private 으로 두고 별도의 public 접근자 메서드를 두는 게 낫다.(아이템16) getter와 같은 메서드를 통해 public 접근이 가능하도록 말이다.
values 메서드
열거 타입은 자신 안에 정의된 상수들의 값을 배열에 담아 반환하는 정적 메서드인 values를 제공한다. 값들은 선언된 순서로 저장된다. toString 은 상수 이름을 문자열로 반환하므로 prinln과 printf로 출력하기에 안성맞춤이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
// 어떤 객체의 지구에서의 무게를 입력받아 여덟 행성에서의 무게를 출력한다. (212쪽)
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에서의 무게는 3.779067이다.
VENUS에서의 무게는 9.050510이다.
EARTH에서의 무게는 10.000000이다.
MARS에서의 무게는 3.796040이다.
JUPITER에서의 무게는 25.296794이다.
SATURN에서의 무게는 10.655141이다.
URANUS에서의 무게는 9.048555이다.
NEPTUNE에서의 무게는 11.362635이다.
*/
1
2
3
4
5
6
7
8
9
10
11
12
public class TestMain {
public static void main(String[] args) {
PayType[] values = PayType.values();
for (PayType value : values) {
System.out.println("value = " + value);
}
}
}
// value = SAMSUNG
// value = APPLE
널리 쓰이는 열거 타입은 톱레벨 클래스로 만들어라.
반면에 특정 톱레벨 클래스에서만 쓰인다면 해당 클래스의 멤버 클래스(아이템24)로 만들어라.
소수 자릿수의 반올림 모드를 뜻하는 열거 타입인 java.math.RoundingMode는 BigDecimal이 사용한다. 그런데 반올림 모드는 BigDecimal과 관련 없는 영역에서도 유용한 개념이라 자바 라이브러리 설계자는 RoundingMode를 톱레벨로 올렸다.
실제 백엔드 제품을 개발 할 때도 Response 응답 모델에서만 사용되는 열거 타입이라면 inner class를 활용하고 엔티티나 여러 도메인 모델에서 사용된다면 톱레벨 클래스로 만들도록 하자.
열거 타입에서 값에 따라 분기처리하는 메서드를 구현하는 법
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
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;
default: throw new AssertionError("알 수 없는 연산: " + this);
}
}
}
- 위 예제는 정상적으로 동작하지만 아름답지 않다.
- 마지막의 throw 문은 실제로는 도달할 일이 없지만 기술적으로 도달할 수 있기에 생략하면 컴파일 조차 되지 않는다.
- 더 나쁜 점은 깨지기 쉬운 코드라는 사실이다.
- 예컨대 새로운 상수를 추가하면 해당 case 문도 추가해야 한다.
- 혹시라도 깜빡한다면, 컴파일은 되지만 새로 추가한 연산을 수행하려 할 때 “알 수 없는 연산”이라는 런타임 오류를 내며 프로그램이 종료된다.
다행히 열거 타입은 상수별로 다르게 동작하는 코드를 구현하는 더 나은 수단을 제공한다. 열거 타입에 apply 라는 추상 메서드를 선언하고 각 상수별 클래스 몸체(constant-specific class body), 즉 각 상수에서 자신에 맞게 재정의하는 방법이다. 이를 상수별 메서드 구현(constant-specific method implementation)이라 한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
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가 추상메서드이므로 재정의하지 않았다면 컴파일 오류로 알려준다.
상수별 메서드 구현을 상수별 데이터와 결합할 수 도 잇따. 예컨대 다음은 Operation의 toString을 재정의해 해당 연산을 뜻하는 기호를 반환하도록 예다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
// 코드 34-6 상수별 클래스 몸체(class body)와 데이터를 사용한 열거 타입 (215-216쪽)
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);
// 코드 34-7 열거 타입용 fromString 메서드 구현하기 (216쪽)
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));
}
public static void main(String[] args) {
double x = 2.0d;
double y = 4.0d;
for (Operation op : Operation.values())
System.out.printf("%f %s %f = %f%n",
x, op, y, op.apply(x, y));
}
}
/*
2.000000 + 4.000000 = 6.000000
2.000000 - 4.000000 = -2.000000
2.000000 * 4.000000 = 8.000000
2.000000 / 4.000000 = 0.500000
*/
valueOf 메서드
열거 타입에는 상수 이름을 입력받아 그 이름에 해당하는 상수를 반환해주는 valueOf(String) 메서드가 자동 생성된다.
한편, 열거 타입의 toString 메서드를 재정의하려거든, toString이 반환하는 문자열을 해당 열거 타입 상수로 변환해주는 fromString 메서드도 함께제공하는 걸 고려해보자.
1
2
3
4
5
6
7
8
// 코드 34-7 열거 타입용 fromString 메서드 구현하기 (216쪽)
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));
}
Note: 만약 toString을 재정의하지 않는 케이스라면 큰 가치가 있진 않은 것 같다고 개인적으로 생각한다.
Operation 상수가 stringToEnum 맵에 추가되는 시점은 열거 타입 상수 생성 후 정적 필드가 초기화 될 때이다.
앞의 코드는 values 메서드가 반환하는 배열 대신 stream을 사용했다. 자바 8 이전에는 빈 해시맵을 만든 다음 values가 반환하는 배열을 순회하면 {문자열, 열거 타입 상수} 쌍을 맵에 추가햇을 것이다. 물론 지금도 이렇게 구현해도 된다. 하지만 열거 타입 상수는 생성자에서 자신의 인스턴스를 맵에 추가할 수 없다. 이렇게 하려면 컴파일 오류가 나는데, 만약 이 방식이 허용되었다면 런타임에 NPE가 발생했을 것이다. 열거 타입의 정적 필드 중 열거 타입의 생성자에서 접근할 수 있는 것은 상수 뿐이다. 열거 타입 생성자가 실행되는 시점에는 정적 필드들이 아직 초기화 되기 전이라, 자기 자신을 추가하지 못하게 하는 제약이 꼭 필요하다. 이 제약의 특수한 예로, 열거 타입 생성자에서 같은 열거 타입의 다른 상수에도 접근할 수 없다.
위의 내용이 직접 실행해본 결과 아래처럼 enum 생성자로 부터 static 필드에 접근할 수 없다는 컴파일 오류가 발생하는 것을 확인할 수 잇다.
1
It is illegal to access static member 'map' from enum constructor or instance initializer
fromString이 Optional을 반환하는 점도 주의하자.
이는 주어진 문자열이 가리키는 연산이 존재하지 않을 수 있음을 클라이언트에 알리고, 그 상황을 클라이언트에서 대처하도록 한 것이다.
Note: 메서드의 리턴 값이 존재하지 않을 수 도 있는 경우에 Optional을 잘 활용하자!
전략 열거 타입 패턴
상수별 메서드 구현에는 열거 타입 상수끼리 코드를 공유하기 어렵다는 단점이 있다. 아래 예제를 살펴보자.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
// 코드 34-8 값에 따라 분기하여 코드를 공유하는 열거 타입 - 좋은 방법인가?
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 = minutedWorked * 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를 구현해놓고, 주말 상수에서만 재정의해 쓰면 장황한 부분은 줄일 수 있다. 하지만 switch문을 썼을 때와 똑같은 단점이 나타난다. 즉, 새로운 상수를 추가하면서 overtimePay 메서드를 재정의하지 않으면 평일용 코드를 그대로 물려받게 되는 것이다.
가장 깔끔한 방법은 새로운 상수를 추가할 때 잔업수당 ‘전략’을 선택하도록 하는 것이다. 다행히 멋진 방법이 있다. 잔업수당 계산을 private 중첩 열거 타입(다음 코드의 PayType)으로 옮기고 PayrollDay 열거 타입의 생성자에서 이 중 적당한 것을 선택하면 된다. 그러면 PayrollDay 열거 타입은 잔업수당 계산을 그 전략 열거 타입에 위임하여, switch 문이나 상수별 메서드 구현이 필요없게 된다. 이 패턴은 switch 문보다 복잡할 수 있지만 더 안전하고 유연한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
// 코드 34-9 전략 열거 타입 패턴 (218-219쪽)
enum PayrollDay {
MONDAY(WEEKDAY), TUESDAY(WEEKDAY), WEDNESDAY(WEEKDAY),
THURSDAY(WEEKDAY), FRIDAY(WEEKDAY),
SATURDAY(WEEKEND), SUNDAY(WEEKEND);
// (역자 노트) 원서 1~3쇄와 한국어판 1쇄에는 위의 3줄이 아래처럼 인쇄돼 있습니다.
//
// MONDAY, TUESDAY, WEDNESDAY, THURSDAY, FRIDAY,
// SATURDAY(PayType.WEEKEND), SUNDAY(PayType.WEEKEND);
//
// 저자가 코드를 간결하게 하기 위해 매개변수 없는 기본 생성자를 추가했기 때문인데,
// 열거 타입에 새로운 값을 추가할 때마다 적절한 전략 열거 타입을 선택하도록 프로그래머에게 강제하겠다는
// 이 패턴의 의도를 잘못 전달할 수 있어서 원서 4쇄부터 코드를 수정할 계획입니다.
private final PayType payType;
PayrollDay(PayType payType) { this.payType = payType; }
// PayrollDay() { this(PayType.WEEKDAY); } // (역자 노트) 원서 4쇄부터 삭제
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));
}
}
/*
MONDAY 480
TUESDAY 480
WEDNESDAY 480
THURSDAY 480
FRIDAY 480
SATURDAY 720
SUNDAY 720
*/
보다시피 switch문은 열거 타입의 상수별 동작을 구현하는데 적합하지 않다. 하지만 기존 열거 타입에 상수별 동작을 혼합해 넣을 때는 switch문이 좋은 선택이 될 수 있다. 예컨대 서드파티에서 가져온 Operation 열거 타입이 있는데, 각 연산의 반대 연산을 반환하는 메서드가 필요하다고 해보자. 다음은 이러한 효과를 내주는 정적 메서드다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
// 코드 34-10 switch 문을 이용해 원래 열거 타입에 없는 기능을 수행한다. (219쪽)
public class Inverse {
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("Unknown op: " + op);
}
}
public static void main(String[] args) {
double x = 2d;
double y = 4d;
for (Operation op : Operation.values()) {
Operation invOp = inverse(op);
System.out.printf("%f %s %f %s %f = %f%n",
x, op, y, invOp, y, invOp.apply(op.apply(x, y), y));
}
}
}
/*
2.000000 + 4.000000 - 4.000000 = 2.000000
2.000000 - 4.000000 + 4.000000 = 2.000000
2.000000 * 4.000000 / 4.000000 = 2.000000
2.000000 / 4.000000 * 4.000000 = 2.000000
*/
열거 타입의 성능
정수 상수와 별반 다르지 않다. 열거 타입을 메모리에 올리는 공간과 초기화하는 시간이 들긴 하지만 체감될 정도는 아니다.
그래서 언제 열거 타입을 쓰란 말인가?
필요한 원소를 컴파일 타입에 다 알 수 있는 상수 집합이라면 항상 열거 타입을 사용하자. 열거 타입에 정의된 상수 개수가 영원히 고정 불변일 필요는 없다. 열거 타입은 나중에 상수가 추가돼도 바이너리 수준에서 호환되도록 설계되었다.
핵심 정리: 열거 타입은 확실히 정수 상수보다 뛰어나다. 더 읽기 쉽고 안전하고 강력하다. 대다수 열거 타입이 명시적 생성자나 메서드 없이 쓰이지만, 각 상수를 특정 데이터와 연결짓거나 상수마다 다르게 돚악하게 할 때는 필요하다. 드물게는 하나의 메서드가 상수별로 다르게 동작해야 할 때도 있다. 이런 열거 타입에서는 switch 문 대신 상수별 메서드 구현을 사용하자. 열거 타입 상수 일부가 같은 동작을 공유한다면 전략 열거 타입 패턴을 사용하자.
전략 열거 타입 실습
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
public enum ElectronicPayType {
SamsungPay("삼성페이", PayStrategy.NORMAL),
LgPay("엘쥐페이", PayStrategy.NORMAL),
LottePay("롯데페이", PayStrategy.NORMAL),
ApplePay("애플페이", PayStrategy.DOUBLE);
private final String label;
private final PayStrategy payStrategy;
public String getLabel() {
return label;
}
ElectronicPayType(String label, PayStrategy payStrategy) {
this.label = label;
this.payStrategy = payStrategy;
}
int pay(int price) {
return payStrategy.pay(price);
}
enum PayStrategy {
NORMAL {
int pay(int price) { return price;}
},
DOUBLE {
int pay(int price) { return price * 2;}
};
abstract int pay(int price);
}
public static void main(String[] args) {
System.out.println(ElectronicPayType.SamsungPay.getLabel() + ": " + ElectronicPayType.SamsungPay.pay(100));
System.out.println(ElectronicPayType.LgPay.getLabel() + ": " + ElectronicPayType.LgPay.pay(100));
System.out.println(ElectronicPayType.LottePay.getLabel() + ": " + ElectronicPayType.LottePay.pay(100));
System.out.println(ElectronicPayType.ApplePay.getLabel() + ": " + ElectronicPayType.ApplePay.pay(100));
}
}
/*
삼성페이: 100
엘쥐페이: 100
롯데페이: 100
애플페이: 200
*/