자바가 기본으로 제공하는 애너테이션 중 보통의 프로그래머에게 가장 중요한 것은 @Override일 것이다. @Override는 메소드 선언에만 달 수 있으며, 이 애너테이션이 달렸다는 것은 상위 타입의 메소드를 재정의했음을 뜻한다. 이 애너테이션을 일관되게 사용하면 여러 가지 악명 높은 버그들을 예방해준다. 다음의 Bigram 프로그램을 살펴보자.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 | // 영어 알파벳 2개로 구성된 문자열을 표현하는 클래스 public class Bigram { private final char first; private final char second; public Bigram(char first, char second) { this.first = first; this.second = second; } public boolean equals(Bigram b) { return b.first == first && b.second == second; } public int hashCode() { return 31 * first + second; } public static void main(String[] args) { Set<Bigram> s = new HashSet<>(); for (int i = 0; i < 10; i++) for (char ch = 'a'; ch <= 'z'; ch++) s.add(new Bigram(ch, ch)); System.out.println(s.size()); } } | cs |
똑같은 소문자 2개로 구성된 바이그램 26개를 10번 반복해 집합에 추가한 다음, 그 집합의 크기를 출력한다. Set은 중복을 허용하지 않으니 26이 출력될 거 같지만, 실제로는 260이 출력된다.
안타깝게도 equals를 '재정의(overrideing)'한 게 아니라 '다중정의(overloading)'해버렸다. Object의 equals를 재정의하려면 매개변수 타입을 Object로 해야만 하는데, 그렇게 하지 않고 Object에서 상속한 equals와는 별개인 equals를 새로 정의한 꼴이 되었다. 이 오류는 컴파일러가 찾아낼 수 있지만, 그러려면 Object.equals를 재정의한다는 의도를 @Override 애너테이션을 달아 명시해야 한다.
그러니 상위 클래스의 메소드를 재정의하려는 모든 메소드에 @Override 애너테이션을 달자. 예외적으로 구체 클래스에서 상위 클래스의 추상 메소드를 재정의할 때는 굳이 @Override를 달지 않아도 된다. 구체 클래스인데 아직 구현하지 않은 추상 메소드가 남아 있다면 컴파일러가 그 사실을 바로 알려주기 때문이다. 물론 재정의 메소드 모두에 @Override를 일괄로 붙여두는 게 좋아 보인다면 그래도 상관없다.
IDE는 @Override를 일관되게 사용하도록 부추기기도 한다. IDE에서 관련 설정을 활성화해놓으면 @Override가 달려있지 않은 메소드가 실제로는 재정의를 했다면 경고를 준다. 재정의할 의도였으나 실수로 새로운 메소드를 추가했을 때 알려주는 컴파일 오류의 보완제 역할로 보면 되겠다.
@Override는 클래스뿐 아니라 인터페이스의 메소드를 재정의할 때도 사용할 수 있다. 디폴트 메소드를 지원하기 시작하면서, 인터페이스 메소드를 구현한 메소드에도 @Override를 다는 습관을 들이면 시그니처가 올바른지 재차 확신할 수 있다. 구현하려는 인터페이스에 디폴트 메소드가 없음을 안다면 이를 구현한 메소드에서는 @Override를 생략해 코드를 조금 더 깔끔히 유지해도 좋으나, 추상 클래스나 인터페이스에서는 상위 클래스나 상위 인터페이스의 메소드를 재정의하는 모든 메소드에 @Override를 다는 것이 좋다.
재정의한 모든 메소드에 @Override 애너테이션을 의식적으로 달면 여러분이 실수했을 때 컴파일러가 바로 알려줄 것이다. 예외는 한 가지뿐이다. 구체 클래스에서 상위 클래스의 추상 메소드를 재정의한 경우엔 이 애너테이션을 달지 않아도 된다(단다고 해서 해로울 것도 없다).