Effective Java - Item 41. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라

마커 인터페이스

• 아무런 메소드를 담지 않고 해당 클래스가 특정 속성임을 표시하기 위해 정의된 인터페이스

 

Serializable이 좋은 예시이다. Serializable을 implements한 클래스는 ObejctOutputStream을 통해 직렬화할 수 있다고 가르쳐 준다.

 

마킹을 하는 용도로 지난 아이템들에서 어노테이션을 살펴봤었다. 마킹의 용도에 있어 어노테이션에 비해 인터페이스의 장점은 클래스의 인스턴스를 구분할 수 있다.

public final void writeObject(Object obj) throws IOException {
// Serializable을 파라미터로 받으면 좋았을 듯
    if (enableOverride) {
        writeObjectOverride(obj);
        return;
    }
    try {
        writeObject0(obj, false);
    } catch (IOException ex) {
        if (depth == 0) {
            writeFatalException(ex);
        }
        throw ex;
    }
}

위의 코드는 잘못 설계된 코드이다. Serializable가 implements가 되어 있지 않은 객체를 wirteObject의 파라미터로 넘기면 (해당 객체의 하위 객체 또한) NotSerializableException이 발생한다. 런타임에서 이를 발견하게 된다. 만약 파라미터로 Serializable을 받았으면 잘못된 객체를 넣어도 컴파일 타임에 에러를 발견할 수 있었을 것이다.

// 근데 writeObject는 객체의 그래프를 그리고 하위 객체가 Serializable이 implements 되어있지 않은 경우에 NotSerializableException이 발생한다. depth가 깊어지면 똑같을 듯

 

어노테이션의 경우는 메소드, 클래스, 필드 등으로 구분할 수는 있지만 어떤 클래스를 구현하고 있는지는 파악할 수 없다. 만약 클래스를 제네릭이나 와일드카드로 설계할 때 마커 인터페이스는 컴파일 타임에 인스턴스 타입 체킹이 가능하다. 조금 더 세밀한 구분이 가능해진다.

 

 

어노테이션의 이점은 무엇일까? 이런 어노테이션을 메인으로 작동하는 프레임워크가 지원해주는 편리한 기능을 사용할 수 있다. Spring의 경우도 어노테이션에 대한 지원이 많다. 이런 경우에 이를 일관되게 사용하는 게 유리하다.

 

 

마커 어노테이션, 마커 인터페이스 사용하는 기준 정리

어노테이션

• 클래스와 인터페이스 외의 요소를 마킹할 때
  • 아이템 39에서 ElementType.Type(클래스, 인터페이스)를 제외한 요소 (메소드, 필드 등)을 적용할 때 어노테이션을 사용할 수밖에 없다.

인터페이스

• 클래스, 인터페이스에 표시하는 경우
  • 이런 경우 마커 인터페이스를 통해 컴파일 타임에 에러를 확인할 수 있다.