티스토리 뷰
자바가 기본으로 제공하는 애너테이션 중 보통의 프로그래머에게 가장 중요한 것은 @Override일 것입니다.
@Override는 메서드 선언에만 달 수 있으며, 이 애너테이션이 달렸다는 것은 상위 타입의 메서드를 재정의했음을 뜻합니다.
이 애너테이션을 일관되게 사용하면 여러 가지 악명 높은 버그들을 예방해줍니다.
다음의 Bigram 프로그램을 살펴봅시다.
이 클래스는 바이그램, 즉 여기서는 영어 알파벳 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 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());
}
}
main 메서드를 보면 똑같은 소문자 2개로 구성된 바이그램 26개를 10번 반복해 집합에 추가한 다음, 그 집합의 크기를 출력합니다.
Set은 중복을 허용하지 않으니 26이 출력될 거 같지만, 실제로는 260이 출력됩니다.
확실히 Bigream 작성자는 eqauls 메서드를 재정의하려 한 것으로 보이고(아이템 10) hashCode도 함께 재정의해야 한다는 사실을 잊지 않았습니다.(아이템 11)
그런데 안타깝게도 equals를 '재정의(overriding)'한 게 아니라 '다중 정의(overloading, 아이템 52)'해버렸습니다.
Object의 equals를 재정의하려면 매개변수 타입을 Object로 해야만 하는데, 그렇게 하지 않은 것입니다.
그래서 Object에서 상속한 equals와는 별개인 equals를 새로 정의한 꼴이 되었습니다.
Object의 equals는 == 연산자와 똑같이 객체 식별성만을 확인합니다.
따라서 같은 소문자를 소유한 바이그램 10개 각각이 서로 다른 객체로 인식되고, 결국 260을 출력한 것입니다.
다행히 이 오류는 컴파일러가 찾아낼 수 있지만, 그러러면 Object.eqauls를 재정의한다는 의도를 명시해야 합니다.
@Override public boolean equals(Bigram b) {
return b.first == first && b.second == second;
}
이처럼 @Override 애너테이션을 달고 다시 컴파일하면 다음의 컴파일 오류가 발생합니다.
Bigram.java:10: method does not override or implement a method
from a supertype
@Override public boolean equals(Bigram b) {
^
잘못된 부분을 명확히 알려주므로 곧장 올바르게 수정할 수 있습니다.
@Override public boolean equals(Object o) {
if (!(o instanceof Bigram))
return false;
Bigram b = (Bigram) o;
return b.first == first && b.second == second;
}
그러니 상위 클래스의 메서드를 재정의하려는 모든 메서드에 @Override 애너테이션을 답시다.
예외는 한 가지뿐입니다.
구체 클래스에서 상위 클래스의 추상 메서드를 재정의할 때는 굳이 @Override를 달지 않아도 됩니다.
구체 클래스인데 아직 구현하지 않은 추상 메서드가 남아 있다면 컴파일러가 그 사실을 바로 알려주기 때문입니다.
물론 재정의 메서드 모두에 @Override를 일괄로 붙여두는 게 좋아 보인다면 그래도 상관없습니다.
또한 대부분의 IDE는 재정의할 메서드를 선택하면 @Override를 자동으로 붙여주니 참고합시다.
한편, IDE는 @Override를 일관되게 사용하도록 부추기기도 합니다.
IDE에서 관련 설정을 활성화해놓으면 @Override가 달려있지 않은 메서드가 실제로는 재정의를 했다면 경고를 줍니다.
@Override를 일관되게 사용한다면 이처럼 실수로 재정의했을 때 경고해줄 것입니다.
재정의할 의도였으나 실수로 새로운 메서드를 추가했을 때 알려주는 컴파일 오류의 보완재 역할로 보면 됩니다.
IDE와 컴파일러 덕분에 우리는 의도한 재정의만 정확하게 해낼 수 있는 것입니다.
@Override는 클래스뿐 아니라 인터페이스의 메서드를 재정의할 때도 사용할 수 있습니다.
디폴트 메서드를 지원하기 시작하면서, 인터페이스 메서드를 구현한 메서드에도 @Override를 다는 습관을 들이면 시그니처가 올바른지 재차 확신할 수 있습니다.
구현하려는 인터페이스에 디폴드 메서드가 없음을 안다면 이를 구현한 메서드에서는 @Override를 생략해 코드를 조금 더 깔끔히 유지해도 좋습니다.
하지만 추상 클래스나 인터페이스에서는 상위 클래스나 상위 인터페이스의 메서드를 재정의하는 모든 메서드에 @Override를 다는 것이 좋습니다.
상위 클래스가 구체 클래스든 추상 클래스든 마찬가지입니다.
예컨대 Set 인터페이스는 Collection 인터페이스를 확장했지만 새로 추가한 메서드는 없습니다.
따라서 모든 메서드 선언에 @Override를 달아 실수로 추가한 메서드가 없음을 보장했습니다.
정리
- 재정의한 모든 메서드에 @Override 애너테이션을 의식적으로 달면 실수했을 때 컴파일러가 알려줄 것이다.
- 예외는 한 가지뿐이다.
- 구체 클래스에서 상위 클래스의 추상 메서드를 재정의한 경우엔 이 애너테이션을 달지 않아도 된다.
'JAVA > 이펙티브 자바' 카테고리의 다른 글
아이템[42]. 익명 클래스보다는 람다를 사용하라 (0) | 2022.04.24 |
---|---|
아이템[41]. 정의하려는 것이 타입이라면 마커 인터페이스를 사용하라 (0) | 2022.04.21 |
아이템[39]. 명명 패턴보다 애너테이션을 사용하라 (0) | 2022.04.21 |
아이템[38]. 확장할 수 있는 열거 타입이 필요하면 인터페이스를 사용하라 (0) | 2022.04.21 |
아이템[37]. ordinal 인덱싱 대신 EnumMap을 사용하라 (0) | 2022.04.18 |
- Total
- Today
- Yesterday
- 디자인 패턴
- kkoon9
- BOJ
- 알고리즘
- 백준
- programmers
- Olympiad
- Kotlin
- Java
- Effective Java
- 테라폼
- AWS
- Spring
- 클린 코드
- MSA
- 프로그래머스
- node.js
- Spring Boot
- BAEKJOON
- 코테
- 클린 아키텍처
- 이펙티브 자바
- Algorithm
- C++
- JPA
- 정규표현식
- 디자인패턴
- 이팩티브 자바
- kotest
- 객체지향
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |