@Override 애너테이션을 일관되게 사용하라 - [6장. 열거 타입과 애너테이션(아이템40)]

  @Override 애너테이션은 메서드 선언에만 달 수 있으며, 이 애너테이션이 달렸다는 것은 상위 타입의 메서드를 재정의했음을 뜻한다.

  @Override 애너테이션을 일관되게 사용하면 여러 가지 악명 높은 버그들을 예방해 준다.

  이번 글을 통해 @Override 애너테이션을 사용하지 않았을 때의 문제점과 @Override 애너테이션을 사용했을 때의 장점 및 사용에 대해서 알아보도록 하자.

 

📙 1. @Override 애너테이션을 사용하지 않았을 때의 문제점

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;
    }
}

Bigram 클래스는 영어 알파벳 2개(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());
}

  위의 코드에서 Set은 중복을 허용하지 않으므로 'a'부터 'z'까지의 알파벳 개수인 26이 출력될 거라고 생각할 수 있다.
  하지만, 260이 출력된다.

  equals와 hashCode 메서드가 잘 있는데 왜 그럴까?

  그 이유는 equals를 '재정의(Overriding)'한 게 아니라 '다중정의(Overloading)' 했기 때문이다.

  Object의 equals를 재정의하려면 매개변수 타입을 Object로 해야만 한다. 그래서 Bigram에서는 Object에서 상속한 equals를 재정의한 게 아니라 별개의 equals를 재정의한 것이다.

 

  그래서 아래와 같이 @Override를 붙여서 컴파일러에게 재정의 한다는 의도를 명시해야 한다.

@Override
public boolean equals(Bigram b) {
    return b.first == first && b.second == second;
}

  물론 이렇게 하면 다음과 같이 컴파일 오류가 난다.

java: method does not override or implement a method from a supertype

  그래서 최종적으로 아래와 같이 equals를 재정의해야 한다.

@Override
public boolean equals(Object o) {
    if(!(o instanceof Bigram))
        return false;
    Bigram b = (Bigram) o;
    return b.first == first && b.second == second;
}

  그러면 우리가 예측한 'a'부터 'z'까지의 알파벳 개수인 26이 출력된다.

 

 

📙 2. @Override 애너테이션을 사용했을 때의 장점 및 사용

  위의 예시에서도 확인할 수 있듯이, 재정의한 모든 메서드에 @Override 애너테이션을 다는 것이 좋다.

  그러면 우리가 실수했을 때 컴파일러가 바로 알려줄 수 있기 때문이다.

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

 

  @Override는 클래스뿐만 아니라 인터페이스의 메서드를 재정의할 때도 사용할 수 있다.

  디폴트 메서드를 지원하기 시작하면서, 인터페이스 메서드를 구현한 메서드에도 @Override를 다는 습관을 들이면 시그니처가 올바른지 재차 확인할 수 있다.

  구현하려는 인터페이스에 디폴트 메서드가 없음을 안다면 이를 구현한 메서드에서는 @Override를 생략해 코드를 조금 더 깔끔히 유지해도 좋다.

 

  하지만, 추상 클래스나 인터페이스에서는 상위 클래스나 상위 인터페이스의 메서드를 재정의하는 모든 메서드에 @Override를 다는 것이 좋다. 상위 클래스가 구체 클래스든 추상 클래스든 마찬가지다.

  예컨대 Set 인터페이스는 Collection 인터페이스를 확장했지만 새로 추가한 메서드는 없다. 그래서 모든 메서드 선언에 @Override를 달아 실수로 추가한 메서드가 없음을 보장했다.

 

해당 글은 Joshua Block 님의 'Effective Java 3/E'를 참고하였습니다.