[item 39] 명명 패턴보다 애너테이션을 사용하라

전통적으로 도구나 프레임워크가 특별히 다뤄야 할 프로그램 요소에는 구분되는 명명 패턴을 적용해왔다. (ex. 테스트 메서드의 이름은 무조건 test로 시작해야 했다.)

이 방법의 단점

1. 오타가 나면 안된다. (JUnit3은 오타가 난 메서드를 실행을 안하고 지나쳐 개발자는 테스트가 통과했다고 오해할 수 있다.)
2. 올바른 프로그램 요소에서만 사용되리라 보증할…

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

마커 인터페이스는 마커 애너테이션보다 나은 2가지 이유

1. 마커 인터페이스는 이를 구현한 클래스의 인스턴스들을 구분하는 타입으로 쓸 수 있으나, 마커 애너테이션은 그렇지 않다. 마커 인터페이스를 사용하면 오류를 컴파일타임에 잡을 수 있는 장점이 있다.
2. 적용 대상을 더 정밀하게 지정할 수 있다. 마커 인터페이스를 정의하고 마킹하고 싶은 클래스에서만 그 인터페이스를 상속받으면 그…

[item 40] @Override 애너테이션을 일관되게 사용하라

@Override 는 메서드 선언에만 달 수 있으며, 애너테이션이 달렸다는 것은 상위 타입의 메서드를 재정의했음을 뜻한다. 이 애너테이션을 일관되게 사용하면 여러가지 버그를 막을 수 있다.

구체 클래스에서 상위 클래스의 추상 메서드를 재정의할 때는 굳이 @Override를 달지 않아도 된다. 구체 클래스인데 아직 구현하지 않은 추상 메서드가 남아 있다면 컴파일러가 그 사실을 바로 알려주기 때문이다.