DEV ℧ Developer Diary

[EffectiveJava] item38 - 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라

열거 타입은 거의 모든 상황에서 이 책초판에서 소개한 타입의 안전 열거 패턴보다 우수하다.

단, 예외가 하나 있으니, 타입 안전 열거 패턴은 확장할 수 있으니 열거 타입은 그럴 수 없다는 점이다.
달리 말하면, 타입 안전 열거 패턴은 열거한 값들을 그대로 가져온 다음 값을 더 추가하여 다른 목적으로 쓸 수 있지만, 열거타입은 그렇게 할 수 없다.

확장한 타입의 원소는 기반 타입의 원소로 취급하지만 그 반대는 성립하지 않는다면 이상하지 않은가? 이것은 실수로 이렇게 설계한 것이 아니다.

그런데 확장할 수 있는 열거 타입이 어울리는 쓰임이 최소한 하나는 있는데, 바로 연산 코드(operation code)이다.
연산 코드의 각 원소는 특정 기계가 수행하는 연산을 뜻한다.
이따금 API가 제공하는 기본 연산 외 사용자 확장 연산을 추가할 수 있도록 열어줘야 할 때가 있다.

interface를 통한 열거 타입 확장

다행히 열거 타입으로 이 효과를 낼 수 있는 방법이 있다.

기본 아이디어는 열거 타입이 임의의 인터페이스를 구현할 수 있다는 사실을 이용하는 것이다.

연산 코드용 인터페이스를 정의하고, 열거 타입이 이 인터페이스를 구현하면 된다.

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; }
  },
  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;

  BasicOperation(String symbol) {
    this.symbol = symbol;
  }

  @Override
  public String toString() {
    return this.symbol;
  }
}

열거 타입인 BasicOperation은 확장할 수 없지만 인터페이스는 Operation은 확장할 수 있고, 이 인터페이스를 연산의 타입으로 사용하면 된다.

이렇게 하면 Operation을 구현한 또 다른 열거 타입을 정의해 기본 타입인 BasicOperaion을 대체할 수 있다.

예를 들어 앞의 코드에 연산타입을 확장해 지수 연산(EXP)와 나머지 연산(REMAINDER)를 추가한 ExtendeOpration 열거 타입을 생성해보자.

public enum ExtendedOperation implements Operation {
  EXP("^") {
    public double apply(double x, double y) { return Math.pow(x, y); }
  },
  REMAINDER("%") {
    public double apply(double x, double y) { return x % y; }
  };

  private final String symbol;

  ExtendedOperation(String symbol) {
    this.symbol = symbol;
  }

  @Override
  public String toString() {
    return this.symbol;
  }
}

확장한 열거타입의 실행

Operation 인터페이스를 구현한 열거 타입을 추가한다면 어디서든 사용할 수 있다.

개별 인스턴스 수준에서뿐 아니라 타입 수준에서도, 기본 열거 타입 대신 확장된 열거 타입을 넘겨 확장된 열거 타입의 원소 모두를 사용하게 할 수도 있다.

class BasicOperationTest {
    @Test
    void 연산_Enum_Test() {
        double x = Double.parseDouble("1.5");
        double y = Double.parseDouble("2.0");
        testOperation(BasicOperation.class, x, y);
        testOperation(ExtendedOperation.class, x, y);
    }

    private <T extends Enum<T> & Operation> void testOperation(Class<T> opEnumType, double x, double y) {
        for (Operation op : opEnumType.getEnumConstants())
            System.out.printf("%f %s %f = %f%n",
                    x, op, y, op.apply(x,y));
    }
}

해당 코드를 실행하면 다음과 같은 결과가 나온다.

1.500000 + 2.000000 = 3.500000
1.500000 - 2.000000 = -0.500000
1.500000 * 2.000000 = 3.000000
1.500000 / 2.000000 = 0.750000
1.500000 ^ 2.000000 = 2.250000
1.500000 % 2.000000 = 1.500000

@Test 메서드는 testOperation 메서드에 BasicOperation의 class 리터럴을 넘겨 확장된 연산들이 무엇인지 알려준다.

여기서 class 리터럴은 한정적 타입 토큰 역할을 한다. opEnumType 매개변수의 선언(<T extends Enum<T> & Operation> Class<T>)은 좀 복잡한데,
해당 선언은 Class 객체가 열거 타입인 동시에 Opeation의 하위 타입이어야 한다는 뜻이다. 열거 타입이어야 원소를 순회할 수 있고, Operation이어야 원소가 뜻하는 연산을 수행할 수 있기 때문이다.

두번째 대안은 Class 객체 대신 한정적 와일드카드 타입인 Collection\<? extends Operation\>을 넘기는 방법이다.

@Test
void 연산_Enum_wildcard_Test() {
    double x = Double.parseDouble("1.5");
    double y = Double.parseDouble("2.0");
    testOperationByWildCard(Arrays.asList(BasicOperation.values()), x, y);
    testOperationByWildCard(Arrays.asList(ExtendedOperation.values()), x, y);
}

private void testOperationByWildCard(Collection<? extends Operation> opSet, double x, double y) {
    for (Operation op : opSet)
        System.out.printf("%f %s %f = %f%n",
            x, op, y, op.apply(x,y));
}

이 코드는 그나마 덜 복잡하고 testOperationByWildCard메서드가 살짝 더 유연해졌다. 다시 말해 여러 구현 타입의 연산을 조합해 호출할 수 있게 되었다.
반면, 특정 연산에서는 EnumSet(Item 36)과 EnumMap(Item 37)을 사용하지 못한다.

인터페이스를 이용해 확장 가능한 열거 타입을 흉내 내는 방식에도 한 가지 사소한 문제가 있다. 바로 열거 타입끼리는 구현을 상속할 수 없다는 점이다.

아무 상태에도 의존하지 않는 경우에는 디폴트 구현(Item 20)을 이용해 인터페이스에 추가하는 방법이 있다.
반면 Operation 에는 연산 기호를 저장하고 찾는 로직이 구현한 BasicOperation과 ExtendedOperation모두에 들어가야만 한다.

이 경우에는 중복량이 적으니 문제되진 않지만, 공유하는 기능이 많다면 그부분의 별도의 도우미 클래스나 정적 도우미 메서드로 분리하는 방식으로 코드 중복을 없앨 수 있을 것이다.

자바 라이브러리도 이번 아이템에 소개한 패턴을 사용한다.

그예시로 java.nio.file.LinkOption 열거 타입은 CopyOption과 OpenOption 인터페이스를 구현했다.

public enum LinkOption implements OpenOption, CopyOption {
    /**
     * Do not follow symbolic links.
     *
     * @see Files#getFileAttributeView(Path,Class,LinkOption[])
     * @see Files#copy
     * @see SecureDirectoryStream#newByteChannel
     */
    NOFOLLOW_LINKS;
}