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

마커 인터페이스

---

아무 메소드도 담고 있지 않고, 단지 자신을 구현하는 클래스가 특정 속성을 가짐을 표시해주는 인터페이스

 

대표적으로 Serializable 인터페이스는 자신을 구현한 클래스의 인스턴스는 ObjectOutputStream을 통해 쓸(write) 수 있다고,

즉 직렬화(serialization)할 수 있다고 알려준다.

 

 

마커 인터페이스와 마커 애노테이션의 비교

---

1. 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있고 마커 애노테이션은 그렇지 않다.

마커 인터페이스는 어엿한 타입이기에 마커 애노테이션을 사용했다면 런타임에야 발견될 오류를 컴파일 타임에 잡을 수 있다.

자바의 직렬화는 위에서 설명한 Serializable 마커 인터페이스를 보고 그 대상이 직렬화할 수 있는 타입인지 확인한다.

 

아래의 코드를 보자.

 

public class MelonBread implements Serializable { }

public class ChocoBread {
    public static void main(String[] args) {
        MelonBread melonBread = new MelonBread();
        try {
            FileOutputStream fos = new FileOutputStream("kTae.txt");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(melonBread);
            oos.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

 

MelonBread는 Serializable을 구현했기 때문에 정상적으로 kTae.txt 파일을 만들어낸다.

 

ObjectOutputStream.writeObject 메소드는 인수로 받은 객체가 Serializable을 구현했을 거라고 가정한다.

이 메소드는 Object 객체를 받도록 설계되었는데, 직렬화 할 수 없는 객체를 넘겨도 런타임에 문제를 알 수 있다.

하지만 마커 인터페이스를 사용하는 주 이유는 컴파일 타임 오류 검출인데 그 이점을 살리지 못했다.

 

그러면 MelonBread 클래스의 implements Serializable 지우고 다시 실행해보자. 예상대로 어떤 컴파일 에러나 경고가 뜨지않는다.

 

 

실행하면 NotSerializableException을 던진다. 예외를 던진 ObjectOutputStream의 writeObject0 메소드로 찾아가보자.

 

 

현재 write할 obj가 String일 때, Array일 때, Enum일 때 각각을 처리하고 Serializable를 구현한 타입에 대해서도 처리한다.

즉 여기서 Serializable을 implements 했는지 검사하고, 하지 않았다면 NotSerializableException을 던지는 것이었다.

 

 

2. 마커 인터페이스가 적용 대상을 더 정밀하게 지정할 수 있다.

적용 대상(@Target)을 ElementType.TYPE으로 선언한 애노테이션은 모든 타입에 달 수 있다.

이 말인 즉, 부착할 수 있는 타입을 더 세밀히 제한하지 못한다는 뜻이다.

 

그런데 특정 인터페이스를 구현한 클래스에만 적용하고 싶은 마커가 있다고 해보자. 

이 마커를 인터페이스로 정의했다면 마킹하고 싶은 클래스에서만 그 인터페이스를 구현(인터페이스라면 확장)하면 된다.

그러면 마킹된 타입은 자동으로 그 인터페이스의 하위 타입임이 보장된다.

 

작자는 이에대한 예시로 Set 인터페이스도 일종의 제약이 있는 마커 인터페이스로 볼 수 있다고 했다. 

• Set은 Collection의 하위 타입에만 적용할 수 있으며, Collection이 정의한 메소드 외에는 새로 추가한 것이 없다.
• add, equals, hashCode등 Collection의 메소드 몇 개의 규약을 수정했기 때문에 마커 인터페이스로 볼 수 없을 수도 있지만, 특정 인터페이스의 하위 타입에만 적용할 수 있으며 아무 규약에도 손대지 않은 마크 인터페이스는 충분히 있음직 하다고 볼 수 있다.
•  객체의 특정 부분을 불변식으로 규정하거나, 그 타입의 인스턴스는 다른 클래스의 특정 메소드가 처리할 수 있다는 사실을 명시하는 용도로 사용할 수 있을 것이다(Serializable 인터페이스가 ObjectOutputStream이 처리할 수 있는 인스턴스임을 명시하듯이)

몇 개의 규악이 수정된 내용은 아래 사이트를 참조했다.

[아이템 41] Set을 마커 인터페이스로 생각하지 않는 이유 · Issue #100 · Java-Bom/ReadingRecord

 

3. 마커 애노테이션은 대신 거대한 애노테이션 시스템의 지원을 받을 수 있다. 마커 인터페이스는 불가능하다.

애노테이션을 적극 활용하는 프레임워크에서는 마커 애노테이션을 쓰는게 일관성을 지키는데는 더 유리하다.

 

 

 

마커 애너테이션과 마커 인터페이스의 사용 시점

---

마커를 클래스나 인터페이스에 적용해야 한다면

"이 마킹이 된 객체를 매개변수로 받는 메소드를 작성할 일이 있을까?" 자문해보자. 그렇다면 마커 인터페이스를 써야한다.

이렇게 하면 그 마커 인터페이스를 해당 메소드의 매개변수 타입으로 사용해 컴파일 타임에 오류를 잡아낼 수 있다.

그리고 새로 추가하는 메소드 없이 단지 타입 정의가 목적이라면 마커 인터페이스를 선택하자.

 

이런 메소드를 작성할 일은 절대 없다고 확신한다면 마커 애노테이션이 나은 선택일 것이다.

추가로 애노테이션을 활발히 활용하는 프레임워크에서 사용하려는 마커라면 마커 애노테이션을 사용하는 편이 낫다.

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

클래스나 인터페이스만이 인터페이스를 구현하거나 확장할 수 있기 때문이다.

 

적용 대상이 ElementType.TYPE인 마커 애노테이션을 작성하고 있다면 마커 인터페이스가 낫진 않을지 고민하자.

 

 

* 위 글은 EffectiveJava 3/E 책 내용을 정리한 글로, 저작권 관련 문제가 있다면 댓글로 남겨주시면 즉각 삭제조치 하겠습니다.