아무 메서드도 담고 있지 않고, 단지 자신을 구현하는 클래스가 특정 속성을 가짐을 표시해주는 인터페이스를 마커 인터페이라 한다.
Serializable 인터페이스 좋은 예다.
클래스의 인스턴스는 ObjectOutputStream을 통해 쓸 수 있다고, 즉 직렬화 할 수 있다고 알려준다.
마커 애너테이션이 등장하면서 마커 인터페이스는 구식이 되었다.
하지만 사실이 아니다.
마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있다.
또, 적용 대상을 더 정밀하게 지정할 수 있다.
적용 대상을 ElementType.TYPE 으로 선언한 애너테이션은 모든 타입에 달 수 있다.
부착하는 타입을 더 세밀하게 제한하지는 못한다는 뜻이다.
Set 인터페이스도 일종의 마커 인터페이스로 볼 수 있다.
Set은 Collection의 하위 타입에만 적용할 수 있으며, Collection이 정의한 메서드 외에는 새로 추가한 것이 없다.
이런 마커 인터페이스는 객체의 특정 부분을 불변식으로 규정하거나, 그 타입의 인스턴스는 다른 클래스의 특정 메서드가 처리할 수 있다는 사실을 명시하는 용도로 사용할 수 있을 것이다.
반대로 마커 애너테이션이 마커 인터페이스보다 나은 점으로는 거대한 애너테이션 시스템의 지원을 받는다는 점을 들 수 있다.
따라서 애너테이션을 적극 활용하는 프레임워크에서는 마커 애너테이션을 쓰는 쪽이 일관성을 지키는 데 유리할 것이다.
마커 인터페이스와 마커 애너테이션은 각자의 쓰임이 있다.
새로 추가하는 메서드 없이 단지 타입 정의가 목적이라면 마커 인터페이스를 선택하자.
클래스나 인터페이스 외의 프로그램 요소에 마킹해야 하거나, 애너테이션을 적극 활용하는 프레임워크의 일부로 그 마커를 편입시키고자 한다면 마커 애너테이션이 올바른 선택이다.
적용 대상이 Element.Type인 마커 애너테이션을 작성하고 있다면, 잠시 여유를 갖고 정말 애너테이션으로 구현하는게 옳은지, 혹은 마커 인터페이스가 낫지는 않을지 곰곰이 생각해보자.
'JAVA > 이펙티브 자바' 카테고리의 다른 글
43. 람다보다는 메서드 참조를 사용하라 ( 람다 표현식과 메서드 참조 ) (0) | 2023.08.02 |
---|---|
42. 익명 클래스보다는 람다를 사용하라 ( 람다 표현식 ) (0) | 2023.07.31 |
40. @Override 애너테이션을 일관되게 사용하라 ( @Override ) (0) | 2023.07.24 |
39. 명명 패턴보다 애너테이션을 사용하라 (0) | 2023.07.20 |
38. 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라 (0) | 2023.07.20 |