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

아무 메서드도 담고 있지 않고, 단지 자신을 구현하는 클래스가 특정 속성을 가짐을 표시해주는 인터페이스를 마커 인터페이스(marker interface)라고 합니다.

Serializable 인터페이스가 좋은 예입니다.

Serializable은 자신을 구현한 클래스의 인스턴스는 ObjectOutputStream을 통해 쓸(write) 수 있다고, 즉 직렬화할 수 있다고 알려줍니다.

마커 애너테이션(아이템 39)이 등장하면서 마커 인터페이스는 구식이 되었다는 이야기가 있습니다.

하지만 이것은 사실이 아니며 마커 인터페이스는 두 가지 면에서 마커 애너테이션보다 낫습니다.

[1]. 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있다.

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

자바의 직렬화는 Serializable 마커 인터페이스를 보고 그 대상이 직렬화할 수 있는 타입인지를 확인합니다.

예를 들어 ObjectOutputStream.writeObject 메서드는 당연히 인수로 받은 객체가 Serializable을 구현했을 거라고 가정합니다.

그런데 이 메서드는 Serializable이 아닌 Object 객체를 받도록 설계되었습니다.

즉, 직렬화할 수 없는 객체를 넘겨도 런타임에야 문제를 확인할 수 있습니다.

마커 인터페이스를 사용하는 주요 이유가 컴파일타임 오류 검출인데, 그 이점을 살리지 못한 것입니다.

[2]. 적용 대상을 더 정밀하게 지정할 수 있다.

적용 대상(@Target)을 ElementType.TYPE으로 선언한 애너테이션은 모든 타입(클래스, 인터페이스, 열거 타입, 애너테이션)에 달 수 있습니다.

부착할 수 있는 타입을 더 세밀하게 제한하지는 못한다는 뜻입니다.

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

이 마커를 인터페이스로 정의했다면 그냥 마킹하고 싶은 클래스에서만 그 인터페이스를 구현하면 됩니다.

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

동의하지 않는 사람도 있겠지만, Set 인터페이스도 일종의 마커 인터페이스로 볼 수 있습니다.

Set은 Collection의 하위 타입에만 적용할 수 있으며, Collection이 정의한 메서드 외에는 새로 추가한 것이 없습니다.

보통은 Set을 마커 인터페이스로 생각하지 않는데, add, equals, hashCode 등 Collection의 메서드 몇 개의 규약을 살짝 수정했기 때문입니다.

하지만 특정 인터페이스의 하위 타입에만 적용할 수 있으며, 아무 규약에도 손대지 않은 마커 인터페이스는 충분히 있음직합니다.

이런 마커 인터페이스는 객체의 특정 부분을 불변식으로 규정하거나, 그 타입의 인스턴스는 다른 클래스의 특정 메서드가 처리할 수 있다는 사실을 명시하는 용도로 사용할 수 있을 것입니다.

(Serializable 인터페이스가 ObjectOutputStream이 처리할 수 있는 인스턴스임을 명시하듯이)

반대로 마커 애너테이션이 마커 인터페이스보다 나은 점으로는 거대한 애너테이션 시스템의 지원을 받는다는 점을 들 수 있습니다.

따라서 애너테이션을 적극 활용하는 프레임워크에서는 마커 애너테이션을 쓰는 쪽이 일관성을 지키는 데 유리할 것입니다.

🤔
어떤 때에 마커 애너테이션을, 또 어떤 때에 마커 인터페이스를 써야 할까요?

 

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

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

마커를 클래스나 인터페이스에 적용해야 한다면 "이 마킹이 된 객체를 매개변수로 받는 메서드를 작성할 일이 있을까?" 라고 자문해봅시다.

답이 "그렇다"이면 마커 인터페이스를 써야 합니다.

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

이런 메서드를 작성할 일은 절대 없다고 확신한다면 아마도 마커 애너테이션이 나은 선택일 것입니다.

추가로, 애너테이션을 활발히 활용하는 프레임워크에서 사용하려는 마커라면 마커 애너테이션을 사용하는 편이 좋을 것입니다.

정리

• 마커 인터페이스와 마커 애너테이션은 각자의 쓰임이 있다.
• 새로 추가하는 메서드 없이 단지 타입 정의가 목적이라면 마커 인터페이스를 선택하자.
• 클래스나 인터페이스 외의 프로그램 요소에 마킹해야 하거나, 애너테이션을 적극 활용하는 프레임워크의 일부로 그 마커를 편입시키고자 한다면 마커 애너테이션이 올바른 선택이다.
• 적용 대상이 ElementType.TYPE인 마커 애너테이션을 작성하고 있다면, 잠시 여유를 갖고 정말 애너테이션으로 구현하는게 옳은지, 혹은 마커 인터페이스가 낫지는 않을지 곰곰이 생각해보자.

이번 아이템은 "타입을 정의할 거라면 인터페이스를 쓰라"고 해석할 수도 있으니, 어떤 의미에서는 "타입이 정의할 게 아니라면 인터페이스를 사용하지 말라"고 한 아이템 22를 뒤집은 것으로 볼 수 있습니다.