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

• 아무 메서드도 담고 있지 않고, 단지 자신을 구현하는 클래스가 특정 속성을 가짐을 표시해주는 인터페이스를 마커 인터페이스라 한다.
• Serializable 인터페이스는 좋은 예인데, 자신을 구현한 클래스의 인스턴스는 ObjectOutputStream을 통해 쓸 수 있다고, 즉 직렬화할 수 있다고 알려준다.
• 마커 애너테이션의 등장으로 마커 인터페이스는 구식이 되었을까? 사실이 아니다. 두 가지 면에서 나은 면이 있다.

 

 

• 첫째는, 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있으나, 마커 애너테이션은 그렇지 않다.
• 마커 인터페이스는 어엿한 타입으로, 마커 애너테이션을 사용했다면 런타임에야 발견될 오류를 컴파일 타임에 잡을 수 있다.

 

 

• 마커 인터페이스가 나은 점 두 번째는 적용 대상을 더 정밀하게 지정할 수 있다는 것이다.
• 적용 대상(@Target)을 ElementType.TYPE으로 선언한 애너테이션은 모든 타입에 달 수 있고 더 세밀하게 제한하지는 못한다.
• 그런데 특정 인터페이스를 구현한 클래스에만 적용하고 싶은 마커가 있다고 해보자. 이 마커를 인터페이스로 정의했다면 그저 마킹하고 싶은 클래스에만 그 인터페이스를 구현하면 된다.
• 그러면 마킹된 타입은 자동으로 그 인터페이스의 하위 타입임이 보장된다.

 

 

Set Interface

---

• Set 인터페이스도 일종의 마커 인터페이스로 볼 수 있다.
• Set은 Collection의 하위 타입에만 적용할 수 있으며, Collection이 정의한 메서드 외에는 새로 추가한 것이 없다.
• 보통은 Set을 마커 인터페이스로 생각하지 않는데, add, equals, hashCode 등 Collection의 메서드 몇 개의 규약을 살짝 수정했기 때문이다.

 

 

 

 

• 반대로 마커 애너테이션이 마커 인터페이스보다 나은 점으로는 거대한 애너테이션 시스템의 지원을 받는다는 점을 들 수 있다.
• 따라서 애너테이션을 적극 활용하는 프레임워크에서는 마커 애너테이션을 쓰는 쪽이 일관성을 지키는 데 유리할 것이다.

 

 

 

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

---

• 클래스와 인터페이스 외의 프로그램 요소에 마킹해야 할 때 애너테이션을 쓸 수 밖에 없다
• 클래스와 인터페이스만이 인터페이스를 구현하거나 확장할 수 있기 때문이다.
• 마커를 클래스나 인터페이스에 적용해야 한다면 "이 마킹이 된 객체를 매개변수로 받는 메서드를 작성할 일이 있을까?" 로 자문해보자.

 

 

• 답이 그렇다면 마커 인터페이스를 써야 한다. 
• 이렇게 하면 해당 메서드의 매개변수 타입으로 사용하여 컴파일시점에 오류를 잡아낼 수 있다.
• 이런 메서드를 작성할 일은 절대 없다고 확신한다면 아마 마커 애너테이션이 나은 선택일 것이다.

 

 

 

 

핵심 정리

---

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

 

 

참고 자료 

---

이펙티브 자바