[이펙티브 자바] 6장 : 열거 타입과 애너테이션

자바의 특수한 목적의 참조 타입 2가지

• 클래스의 일종인 ‘열거 타입’
• 인터페이스의 일종인 ‘애너테이션’

이 두가지를 올바르게 사용해보자.

아이템 34 : int 상수 대신 열거 타입을 사용하라

열거 타입은 일정 개수의 상수값 정의 후 그외는 지원하지 않는 타입이다.

열거 타입 이전 상수 선언 (정수 열거 패턴)

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_NEVLE = 0;
public static final int ORANGE_TEMPLE = 1;

단점 →

• 타입 안전 보장 X, (오렌지 대신 사과를 보내도 경고가 발생하지 않는다) ‘==’이 동일하므로
• 상수를 사용한 모든 파일 재컴파일 필요

자바 열거 타입

public enum Apple { FUJI, PIPPIN, GRANNY_SMITH } 
public enum ORANGE { NAVEL, TEMPLE, BLOOD }

• 열거 타입 자체가 클래스이며 상수 하나당 자신의 인스턴스를 만들어 public static final로 공개한다.
  • 생성자를 제공하지 않으므로 인스턴스가 생성불가하고 사실상 final이다. (인스턴스 통제)
  • 싱글턴은 원소가 하나뿐인 열거 타입
• 컴파일 타입 안정성을 제공
• 각자의 네임스페이스 제공함으로 이름이 같아도 공존가능 (APPLE.FUJI, ORANGE.FUJI 가능)
• 메서드나 필드 추가 가능 (상수를 이용한 추가적인 기능 제공)

-Planet-

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, public static final로 공개

만약, 상수를 하나 제거하게 되면 제거한 상수를 참조하지 않는다면 아무런 영향이 없다.

그리고 참조하는 상수를 제거한 곳에서는 컴파일 에러가 발생해 에러를 조기에 찾을 수 있다.

열거 타입 상수마다 동작이 달라지는 메서드 구성

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);

내부 symbol필드에 알맞은 값이 저장되며 toString() 재정의를 통해 symbol값이 반환됨

새로운 상수가 추가 되었을 때 apply()재정의여부를 컴파일에러로 알려준다.

값에 따라 분기하여 코드를 공유하는 열거 타입

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;
    }
}
@Test public void payrollDayTest() {
    int pay1 = PayrollDay.FRIDAY.pay(480, 200);
    System.out.println("pay1 = " + pay1);
    int pay2 = PayrollDay.FRIDAY.pay(540, 200);
    System.out.println("pay2 = " + pay2);
    int pay3 = PayrollDay.SUNDAY.pay(480, 200);
    System.out.println("pay3 = " + pay3);
}

주말과 주중을 분리하여 계산하는 것은 분명 간결하지만 ‘관리 관점' 에서 위험한 코드이다. 만약, 새로운 상수인 휴가가 추가되었는데 pay에 재정의를 하지 않으면 휴가에도 평일과 같은 임금을 받게된다.

• 관리가 어렵고 실수를 유발할 수 있다.

전략 열거 타입 패턴

// 코드 34-9 전략 열거 타입 패턴 (218-219쪽)
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; }
    // 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));
    }
}

새로운 상수를 추가할 때 ‘전략'을 선택하도록 하는 것이다. 이제 PayrollDay는 잔업수당 전략으로 ‘PayType’을 선택할 수 있다.

전략을 미리 정의해두고 생성 시 선택한 전략으로 pay()메서드가 수행된다.

열거 타입 사용 기준

• 필요한 원소를 컴파일 타임에 다 알 수 있는 상수 집합이라면 항상 열거 타입을 사용하자.
• 열거 타입에 정의도니 상수가 영원히 영원 불변일 필요는 없다.

핵심 정리

• 열거타입이 정수 상수보다 가독성도 좋고 안전하다.
• 열거 타입 상수가 같은 코드를 공유한다면, 전략 열거 타입 패턴을 사용하자.

아이템 35 : ordinal 메서드 대신 인스턴스 필드를 사용하라

대부분 열거 타입 상수는 하나의 정숫값에 대응된다. 그리고 ordinal() 메서드는 해당 상수가 열거 타입에서 몇번째 위치하는지 반환한다.

이 메서드를 사용하다가 중간에 상수가 추가되면 위치의 변화로 인해 오류가 발생한다. 따라서 사용하지 말자. (범용 자료구조에서 쓰임)

쓸 일이 있다면 인스턴스 필드로 정의해서 사용하라.

아이템 36 : 비트 필드 대신 EnumSet을 사용하라

비트 필드는 여러 상수를 하나로 모으고 합집합, 교집합 연산에 유리하다.

하지만, 비트이기때문에 정수 상수보다 해석하기 어렵다.

EnumSet - 비트 필드를 대체하는 현대적 기법

public class Text {
    public enum Style {BOLD, ITALIC, UNDERLINE, STRIKETHROUGH}

    // 어떤 Set을 넘겨도 되나, EnumSet이 가장 좋다.
    public void applyStyles(Set<Style> styles) {
        System.out.printf("Applying styles %s to text%n",
                Objects.requireNonNull(styles));
    }

    // 사용 예
    public static void main(String[] args) {
        Text text = new Text();
        text.applyStyles(EnumSet.of(Style.BOLD, Style.ITALIC));
    }
}

EnumSet을 사용하면 비트를 효율적으로 처리하며 비트를 다루는 어려움에서 벗어날 수 있다.

아이템 37 : ordinal 인덱싱 대신 EnumMap을 사용하라

배열의 인덱스를 얻기 위해 ordinal을 쓰는 것은 좋지 않으니 EnumMap을 사용하라

아이템 38 : 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라

열거타입을 확장하는 것은 설계와 구현이 복잡해져서 좋지 않다. (확장도 지원되진 않음)

열거타입이 임의의 인터페이스를 구현가능하므로 확장이 가능하다.

열거 타입 확장

public interface Operation {
  	double apply(double x, double y);
}

public enum BasicOperation implements Operation {
  	PLUS("+") {
      	public double apply(double x, double y) { return x + y; }
    }
  	MINUS("-") {
      	public double apply(double x, double y) { return x - y; }
    }
}

// 확장 가능 열거 타입
public enum ExtendedOperation implements Operation {
  	EXP("^") {
      	public double apply(double x, double y) {
	          return Math.pow(x, y);
        }
    }
}

클래스 받아 실행

@Test 
public void operationTest() {
    double x = 4.0;
    double y = 2.0;
    getEnumClass(BasicOperation.class, x, y);
    getEnumClass(ExtendedOperation.class, x, y);
}
private < T extends Enum < T > & Operation > void getEnumClass(Class < T > enumClass, double x, double y) {
    for (Operation operation : enumClass.getEnumConstants()) {
        System.out.printf("%f %s %f = %f%n", x, operation, y, operation.apply(x, y));
    }
}

컬렉션으로 받아 실행

@Test public void operationTest() {
    double x = 4.0;
    double y = 2.0;
    getEnumCollection(Arrays.asList(BasicOperation.values()), x, y);
    getEnumCollection(Arrays.asList(ExtendedOperation.values()), x, y);
}
private void getEnumCollection(Collection <? extends Operation > opSet, double x, double y) {
    for (Operation operation : opSet) {
        System.out.printf("%f %s %f = %f%n", x, operation, y, operation.apply(x, y));
    }
}

아이템 39 : 명명 패턴보단 애너테이션을 사용하라

명명 패턴 단점

1. 정해진 이름에서 오타가 나면 안된다. (실수 발생)
2. 개발자가 의도한대로 안될 수 있다 (사용법 잘못 이해할 시)
3. 프로그램 요소를 매개변수로 전달할 방법이 없다.

애너테이션을 사용하면 적용된 정보를 이용해 잘못 사용한 위치에서 컴파일 시 오류를 뱉는다.

/**
 * 명시한 예외를 던져야만 성공하는 테스트 메서드용 애너테이션
 */
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface ExceptionTest {
    Class<? extends Throwable> value();
}

어노테이션을 통해 ‘메서드 위치'에 사용했는 지 컴파일 타임에 검사할 수 있고 어노테이션이 어디까지 살아있을 지도 명시할 수 있다.

애너테이션은 관심 있는 프로그램에 추가정보를 제공한다. 즉, 특별한 처리를 할 기회를 준다.

 

-RunTests예시-

public class RunTests {
    public static void main(String[] args) throws Exception {
        int tests = 0;
        int passed = 0;
        Class<?> testClass = Class.forName(args[0]);
        for (Method m : testClass.getDeclaredMethods()) {
            if (m.isAnnotationPresent(Test.class)) {
                tests++;
                try {
                    m.invoke(null);
                    passed++;
                } catch (InvocationTargetException wrappedExc) {
                    Throwable exc = wrappedExc.getCause();
                    System.out.println(m + " 실패: " + exc);
                } catch (Exception exc) {
                    System.out.println("잘못 사용한 @Test: " + m);
                }
            }

            if (m.isAnnotationPresent(ExceptionTest.class)) {
                tests++;
                try {
                    m.invoke(null);
                    System.out.printf("테스트 %s 실패: 예외를 던지지 않음%n", m);
                } catch (InvocationTargetException wrappedEx) {
                    Throwable exc = wrappedEx.getCause();
                    Class<? extends Throwable> excType =
                            m.getAnnotation(ExceptionTest.class).value();
                    if (excType.isInstance(exc)) {
                        passed++;
                    } else {
                        System.out.printf(
                                "테스트 %s 실패: 기대한 예외 %s, 발생한 예외 %s%n",
                                m, excType.getName(), exc);
                    }
                } catch (Exception exc) {
                    System.out.println("잘못 사용한 @ExceptionTest: " + m);
                }
            }
        }

        System.out.printf("성공: %d, 실패: %d%n",
                passed, tests - passed);
    }
}

args인자로 넘어온 클래스에 모든 메서드를 반복하며 어노테이션 적용된 메서드를 호출하며 테스트한다. (어노테이션을 통한 추가적인 처리)

 

위에서 만든 어노테이션과 테스트를 사용한 프로그램을 만들어보자.

public class Sample2 {
    @ExceptionTest(ArithmeticException.class)
    public static void m1() {  // 성공해야 한다.
        int i = 0;
        i = i / i;
    }
    @ExceptionTest(ArithmeticException.class)
    public static void m2() {  // 실패해야 한다. (다른 예외 발생)
        int[] a = new int[0];
        int i = a[1];
    }
    @ExceptionTest(ArithmeticException.class)
    public static void m3() { }  // 실패해야 한다. (예외가 발생하지 않음)
}

어노테이션의 매개변수 타입이 Class<? extends Throwable> 이므로 Throwable을 확장한 모든 클래스를 수용한다.

이를 통해 테스트에서는 ‘실제 발생한 예외'와 ‘어노테이션에 명시된 예외'를 비교해서 성공/실패 여부를 판단할 수 있다.

반복 가능 애너테이션

‘@Repeatable’이 자바8 부터 추가되었다.

이번 아이템에서 보여준 테스트 프레임워크는 간단하지만 명명패턴보단 애너테이션이 낫다는 점을 보여준다.

→ 컴파일 단계 에러 잡기, 어노테이션을 통한 테스트 실행 및 판단

그러므로, 애너테이션으로 할 수 있는 일은 명명 패턴으로 처리할 이유는 없다

아이템 40 : ‘@Override’ 애너테이션을 일관되게 사용하라

오버라이드 애너테이션을 사용하면 명시적으로 재정의 한 것을 표현할 수 있다. 이를 통해 실수로 파라미터 타입을 잘못 적어 다중 정의하는 경우에 컴파일 오류로 바로 잡아낼 수 있다.

그러므로, 상위 클래스의 메서드를 재정의하려는 메서드에는 모두 ‘@Override’ 애너테이션을 달자.

아이템 41 : 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라

아무 메서드도 담고 있지 않고 단지 자신을 구현하는 클래스가 특정 속성을 가짐을 표시해주는 인터페이스를 ***‘마커 이터페이스'***라고 한다.

• 예) Serializable 인터페이스
  • 이를 구현한 클래스는 직렬화할 수 있다고 알려준다.

마커 인터페이스는 마커 애너테이션보다 낫다.

마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있다. (마커 애너테이션은 불가)

→ 마커 인터페이스도 타입이기 때문에 런타임 오류를 컴파일 타임에 잡을 수 있다.

인수로 받은 객체가 Serializable을 구현했을 거라 가정하고 설계된 메서드는 컴파일 타임에 오류를 잡을 수 있다.

마커 인터페이스 vs 마커 애너테이션

• 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있으나, 마커 애너테이션은 그렇지 않다.
• 마커 인터페이스는 적용 대상을 더 정밀하게 지정할 수 있다.
  • 특정 클래스 또는 인터페이스의 하위 타입에만 적용할 수 있다. ex) Set 인터페이스
• 마커 애너테이션은 거대한 애너테이션 시스템의 지원을 받을 수 있다.
  • 애너테이션을 적극 활용하는 프레임워크에서는 애너테이션이 일관성을 지니는 데 유리하다

클래스와 인터페이스 외의 프로그램 요소(모듈, 패키지, 필드, 지역변수 등)에 마킹해야 할 때 애너테이션을 쓸 수 밖에 없다.

“마킹이 된 객체를 매개변수로 받는 메서드를 작성할 일이 있다” 면 마커 인터페이스

어떤 것을 사용하는지 나을지 곰곰이 생각해보자.