목차
· 아이템 10. equals는 일반 규약을 지켜 재정의하라
· 아이템 11. equals를 재정의하려거든 hashCode도 재정의하라
· 아이템 12. toString을 항상 재정의하라
· 아이템 13. clone 재정의는 주의해서 진행하라
· 아이템 14. Comparable을 구현할지 고려하라
· Object는 객체를 만들 수 있는 구체 클래스지만 기본적으로 상속해서 사용하도록 설계되었다.
· Object에서 final이 아닌 메서드(equals, hashCode, toString, clone, finalize)는 모두 재정의(overriding)를 염두에 두고 설계된 것이라 재정의 시 지켜야 하는 일반 규약이 명확히 정의되어 있다.
- 메서드를 잘못 구현하면 대상 클래스가 이 규약을 준수한다고 가정하는 클래스(HashMap과 HashSet 등)이 오작동하게 만들 수 있다.
· 이 장에서는 Object 메서드들이 언제 어떻게 재정의해야 하는지를 다룬다. Comparable.compareTo 또한 성격이 비슷하여 이번 장에서 함께 다룬다.
아이템 10. equals는 일반 규약을 지켜 재정의하라
· equals 메서드는 잘못 재정의하면 끔찍한 결과를 초래한다. 문제를 회피하는 가능 쉬운 길은 아예 재정의 하지 않는 것이다. 그냥 두면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다.
equals를 재정의하지 않아야 하는 상황
1. 각 인스턴스가 본질적으로 고유하다.
- 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스가 여기에 해당한다. ex) Thread
2. 인스턴스의 논리적 동치(logical equality)를 검사할 일이 없다.
3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다.
ex) 대부분의 Set 구현체는 AbstractSet이 구현한 equals를 상속 받아 쓴다. List와 AbstractList, Map과 AbstracMap도 그렇다.
4. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다.
· equals를 실수로라도 호출되는 걸 막고 싶다면 다음처럼 구현해두자.
@Override public boolean equals(Object o) {
throw new AssertionError(); // 호출 금지
}equals를 재정의해야 하는 상황
· 객체 식별성 아니라 논리적 동치성을 확인해야하는 상황이고, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지 않는다면 equals를 재정의해야 한다.
- 주로 값 클래스(Integer, String)들이 여기 해당한다.
- 값 클래스라도 값이 같은 인스턴스가 둘 이상 만들어지지 않음을 보장하는 인스턴스 통제 클래스(아이템 1)라면 equals를 재정의하지 않아도 된다. ex) Enum
- 같은 인스턴스가 2개 이상 만들어지지 않으면, 논리적 동치성과 객체 식별성이 사실상 똑같은 의미가 된다.
- 객체 식별성: Object identity, 두 객체가 물리적으로 같은가
· equals가 논리적 동치성을 확인하도록 재정의하면, Map의 키와 Set의 원소로 사용할 수 있게 된다.
· equals 메서드를 재정의할 때는 반드시 일반 규약을 따라야 한다.
- 이 규약을 어기면 프로그램이 이상하게 동작하거나 종료될 것이고, 원인이 되는 코드는 찾기 굉장히 어려울 것이다.
Object 명세에 적힌 규약
· equals 메서드는 동치관계(equivalence relation)를 구현하며, 다음을 만족한다.
1. 반사성(reflexivity): null이 아닌 모든 참조 값 x에 대해, x.equals(x)는 true다.
- 객체는 자기 자신과 같아야 한다.
2. 대칭성(symmetry): null이 아닌 모든 참조 값 x, y에 대해, x.equals(y)가 true면 y.equals(x)도 true다.
- 두 객체는 서로에 대한 동치 여부에 똑같이 답해야 한다.
3. 추이성(transitivity): null이 아닌 모든 참조 값 x, y, z에 대해, x.equals(y)가 true이고 y.equals(z)도 true면 x.equals(z)도 true다.
- 첫 번째 객체와 두 번째 객체가 같고, 두 번째 객체와 세번째 객체가 같다면, 첫 번째 객체와 세 번째 객체도 같아야 한다.
4. 일관성(consistency): null이 아닌 모든 참조 값 x, y에 대해, x.equals(y)를 반복해서 호출하면 항상 true를 반환하거나 항상 false를 반환한다.
-
5. null-아님: null이 아닌 모든 참조 값 x에 대해, x.equals(null)은 false다.
· 동치관계란 집합을 서로 같은 원소들로 이뤄진 부분집합으로 나누는 연산이다.
- 이 부분집합을 동치류(equivalence class; 동치 클래스)라 한다.
- equals 메서드가 쓸모 있으려면 모든 원소가 같은 동치류에 속한 어떤 원소와도 서로 교환할 수 있어야 한다.
· 구체 클래스를 확장해 새로운 값을 추가하면 equals 규약을 만족시킬 방법이 존재하지 않는다.
(객체 지향적 추상화의 이점을 포기하지 않는 한)
- 이는 추이성을 깨는 행위다.
- 모든 객체 지향 언어의 동치관계에서 나타나는 근본적인 문제다.
- 우회 방법: 상속이 아닌 컴포지션을 사용한다.
양질의 equals 메서드 구현 방법
1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인한다. 자기 자신이면 true를 반환한다.
- 이는 단순한 성능 최적화용이다.
2. instanceof 연산자로 입력이 올바른 타입인지 확인한다. 그렇지 않으면 false를 반환한다.
- 올바른 타입은 equals가 정의된 클래스인 것이 보통이지만, 가끔은 그 클래스가 구현한 특정 인터페이스가 될 수도 있다.
- 어떤 인터페이스는 자신을 구현한 서로 다른 클래스끼리도 비교할 수 있도록 equals 규약을 수정하기도 한다. 이런 인터페이스를 구현한 클래스라면 equals에 클래스가 아닌 해당 인터페이스를 사용해야 한다. ex) Set, List, Map, Map.Entry
3. 입력을 올바른 타입으로 형변환한다.
- 앞서 instanceof 검사를 했기 때문에 이 단계는 100% 성공 한다.
4. 입력 객체와 자기 자신의 대응되는 핵심 필드들이 모두 일치하는지 하나씩 검사한다. 모든 필드가 일치하면 true를 하나라도 다르면 false를 반환한다.
- 2단계에서 인터페이스를 사요했다면 입력 필드 값을 가져올 때도 그 인터페이스의 메서드를 사용해야 한다.
TODO: p63 이후
아이템 11. equals를 재정의하려거든 hashCode도 재정의하라
· equals를 재정의한 클래스 모두에서 hashCode도 재정의 재정의해야 한다.
- 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap, HashSet 등 컬렉션의 원소로 사용할 때 문제가 발생한다.
· 아래는 Object 명세의 hashCode 관련 규약을 발췌한 것이다. hashCode 재정의를 잘못했을 때, 두 번째 조항이 크게 문제가 된다.
- 즉, 논리적으로 같은 객체는 같은 해시코드를 반환해야 한다.
- equals는 물리적으로 다른 두 객체를 논리적으로 같다고 할 수 있다.
하지만 Object의 기본 haCode 메서드는 이 둘이 전혀 다르다고 판단하여 서로 다른 값을 반환한다.
| · equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. · equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. · equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 단, 다른 객체에 대해서는 다른 값을 반환해야 해시테이블의 성능이 좋아진다. |
· 좋은 해시 함수라면 서로 다른 인스턴스에 다른 해시코드를 반환해야한다.
- 위 규약의 세 번째 규약이 요구하는 속성이다.
- 다음은 동치인 모든 객체에서 똑같은 해시코드를 반환하는 최악이지만 적법한 코드다. 모든 객체가 해시테이블 버킷 하나에 담겨 마치 연결 리스트처럼 동작한다. 그 결과 평균 수행 시간이 O(1)인 해시테이블이 O(n)으로 느려진다.
// 최악이지만 적법한 hashCode 구현.
// 동치인 모든 객체에서 똑같은 해시코드를 반환한다.
@Override
public int hashCode() {
return 42;
}
좋은 hashCode를 작성하는 요령
|
· 2.b에서 곱할 숫자를 31로 정한 이유는 31이 홀수이면서 소수(prime)이기 때문이다.
- 이 숫자가 짝수이고 오버플로가 발생한다면 정보를 잃게 된다. 2를 곱하는 것은 시프트 연산과 같은 결과를 내기 때문이다.
- 소수를 곱하는 이유는 명확하지 않고, 전통적으로 그리 해왔다.
- 31을 이용하면 이 곱셈을 시프트 연산과 뺄셈으로 대체해 최적화할 수 있다. (31 * 1 == (1 << 5) - i) 요즘 VM들은 이런 최적화를 자동으로 해준다.
추가적인 팁
· hashCode를 구현했다면, 동치인 인스턴스에 대해 똑같은 해시코드를 반환할지 자문하고, 검증할 단위 테스트를 작성하자.
- equals와 hashCode 메서드를 AutoValue로 생성했다면 건너뛸 수 있다.
· 파생 필드는 해시 코드 계산에서 제외해도 된다.
- 파생 필드: 다른 필드로부터 계산해 낼 수 있는 필드
· equals 비교에 사용되지 않은 필드는 반드시 제외한다.
- 그렇지 않으면 hashCode 규약 두 번째를 어기게 될 수 있다.
· 해시 충돌이 더 적은 방법을 쓰고 싶다면 구아바의 com.google.common.hash.Hashing을 참고하자.
· Objects 클래스는 임의의 개수만큼 객체를 받아 해시코드를 계산해주는 정적 메서드 hash를 제공하여 hashCode 함수를 단 한 줄로 작성할 수 있다.
@Override public int hashCode() {
return Objects.hash(a, b, c);
}- 속도가 느리므로 성능에 민감하지 않은 경우만 사용하자.
(입력 인수를 담기 위한 배열을 만들고, 기본 타입의 박싱 언박싱을 거쳐야 해서 느리다)
· 클래스가 불변이고 해시코드 계산 비용이 크다면, 매번 새로 계산하지 말고 캐싱을 고려하자.
- 해당 타입의 객체가 주로 해시 키로 사용될 것 같다면, 인스턴스가 만들어질 때 미리 해시코드로 계산해둔다.
- 해시의 키로 사용되지 않는 경우라면 hashCode가 처음 불릴 때 지연 초기화 전략을 사용할 수 있다.
- 이 경우 클래스를 스레드 안전하게 만들어야한다.
· 성능을 높인답시고 해시코드를 계산할 때 핵심 필드를 생략하면 안 된다.
- 해시 품질이 나빠져 해시테이블의 성능이 심각하게 떨어질 수 있다.
- 특정 영역에 몰린 인스턴스들의 해시코드를 넓은 범위로 고르게 퍼뜨리는 효과를 가지는 필드일 수도 있다.
· hashCode가 발환하는 값의 생성 규칙을 API 사용자에게 자세히 공표하지 말자.
- 클라이언트가 이 값에 의지하지 않게 되고, (해시 기능의 결함 발견 등의 이유로 )추후 계산 방식을 바꿀 수 있다.
- String, Integer 등 자바 라이브러리는 hashCode 메서드가 반환하는 값을 정확하게 알려주는 부작용이 있다.
아이템 12. toString을 항상 재정의하라
· Object의 기본 toString 메서드는 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우가 거의 없다.
- '클래스이름@16진수로표시된해시코드'를 반환할 뿐이다.
· toString 일반 규약에 따르면 '간결하면서 사람이 읽기 쉬운 형태의 유익한 정보'를 반환해야 하고, '모든 하위 클래스에서 이 메서드를 재정'해야 한다.
· toString을 잘 구현하면, 그 클래스를 사용한 시스템을 디버깅하기 쉽다.
- toString 메서드는 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길 때, 디버거가 객체를 출력할 때 자동으로 불린다.
- toString을 제대로 재정의하지 않는다면 쓸모없는 메시지만 로그에 남는다.
· 좋은 toString은 컬렉션처럼 이 인스턴스를 포함하는 객체에서 유용하게 쓰인다.
ex) {Jenny=PhoneNumber@abbd}보다는 {Jenney=707-867-5309}라는 메시지가 훨씬 반가울 것이다.
· 실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다.
- 단, 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 예외다. 이런 상황에서는 요약 정보를 담도록 하자.
- 이상적으로는 스스로를 완벽하게 설명하는 문자열이어야 한다.
- toString에 주요한 정보가 담기지 않았을 때 문제가 되는 대표적인 예시:
Assertion failure: expected {abc, 123}, but was {abc, 123}.
· toString을 구현할 때면 반환값의 포맷을 문서화할 지 정해야 한다.
- 장점: 포맷을 명시하면 그 객체는 표준적이고 명확하고, 사람이 읽을 수 있게 된다.
- 그 값 그대로 입출력에 사용하거나 CSV 파일처럼 사람이 읽을 수 있는 데이터 객체로 저장할 수도 있다.
- 명시한 포맷에 맞는 문자열과 객체를 상호 전환할 수 있는 정적 팩터리나 새성자를 함께 제공해주면 좋다.
자바 플랫폼에 많은 값 클래스가 따르는 방식이다. ex) BigInteger, BigDecimal
/**
* PhoneNumber 객체(전화번호)의 문자열 표현을 반환한다.
* 문자열은 14자이며 형식은 "(XXX) YYY-ZZZZ"이다.
* 여기서 XXX는 지역번호이고, YYY는 국번, ZZZZ는 선번호이다.
* 각, 영문 대문자는 한 자리의 십진수를 나타낸다.
* 지정된 자리수가 다 채워지지 않은 경우는 세 부분 모두 0을 앞에 붙힌다.
* 예를 들어, 선번호의 값이 123이면, 문자열 표현 시 "0123"이 된다.
* 지역번호의 우 괄호 다음에는 스페이스를 하나 추가한다.
*/
@Override
public String toString() {
return String.format("(%03d) %03d-%04d", areaCode, prefix, lineNumber);
}
- 단점: 포맷을 한 번 명시하면 평생 그 포맷에 얽매이게 된다.
포맷을 명시하지 않으면, 향후 릴리스에서 정보를 더 넣거나 포맷을 개선할 수 있는 유연성을 얻게 된다.
/**
* 이 부분의 간략한 표현을 반환한다.
* 반환 문자열의 형식은 정해지지 않았으므로 변경될 수 있다.
* 일반적인 형태는 다음과 같다 :
*
* "[Potion #9: type=love, smell=turpentine, look=india ink]" */
@Override
public String toString() { ... }
· 정적 유틸리티 클래스(아이템 4)는 toString을 제공할 이유가 없다. 대부분의 열거 타입도 그렇다.
- 대부분의 열거 타입은 자바에서 이미 완벽한 toString을 제공한다.
· 하위 클래스들이 공유해야 할 문자열 표현이 있는 추상 클래스라면 toString을 재정의해줘야 한다.
ex) 다수의 컬렉션 구현체는 추상 컬렉션 클래스들의 toString 메서드를 상속해 쓴다.
TODO: 아이템 13. clone 재정의는 주의해서 진행하라
· Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스(아이템 20)지만, 의도한 목적을 제대로 이루지 못했다.
- clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이고, 그마저도 protected다. 그래서 Cloneable을 구현하는 것만으로는 외부 객체에서 clone 메서드를 호출할 수 없다.
- 리플렉션(아이템 65)을 사용하면 가능하지만, 해당 객체가 접근이 허용된 clone 메서드를 제공한다는 보장이 없다.
· 여러 문제점에도 불구하고 Cloneable 방식은 널리 쓰이고 있다. 따라서 1. clone 메서드를 잘 동작하게끔 해주는 구현 방법과 2. 언제 그렇게 해야하는지 잘알아야한다.
· Cloneable 인터페이스는 Object의 protected 메서드인 clone의 동작 방식을 결정한다.
- Cloneable을 구현한 클래스의 인스턴스에서 clone을 호출하면 그 객체의 필드들을 하나하나 복사한 객체를 반환하며, 그렇지 않은 클래스의 인스턴스에서 호출하면 CloneNotSupportedException을 던진다.
TODO: 아이템 14. Comparable을 구현할지 고려하라
· Comparacle 인터페이스는 compareTo 메서드를 갖는다.
· compareTo는 두 가지만 빼면, Object의 equals와 같다.
- compareTo는 단순 동치성 비교에 더해 1. 순서까지 비교할 수 있으며, 2. 제네릭하다.
- Comparable을 구현했다는 것은 그 클래스의 인스턴스들에는 자연적인 순서(natural order)가 있음을 뜻한다.
public interface Comparable<T> {
int compareTo(T t);
}
· Comparable을 구현한 객체들의 배열을 손쉽게 정렬할 수 있다. Ex) Arrays.sort(a);
- 검색, 극단값 계산, 자동 정렬되는 컬렉션 관리도 쉽게 할 수 있다.
// 명령줄 인수들을 (중복 제거 후) 알파벳순으로 출력한다.
// String이 Comparable을 구현한 덕분에 가능하다.
public class WordList
{
putlic static void main(String[] args)
{
Set<String> s = new TreeSet<>();
Collections.addAll(s, args);
System.out.println(s);
}
· Comparable을 구현하면, 이 인터페이스를 활용하는 수많은 제네릭 알고리즘과 컬렉션의 힘을 누릴 수 있다.
- 자바 플랫폼 라이브러리의 거의 모든 값 클래스와 열겨 타입은 Comparable을 구현한다.
- 알파벳, 숫자, 연대 같이 순서가 명확한 값 클래스를 작성한다면 반드시 Comparable 인터페이스를 구현하자.
· compareTo 메서드의 일반 규약은 equals의 규약과 비슷하다.
| 이 객체와 주어진 객체의 순서를 비교한다. 이 객체가 주어진 객체보다 작으면 음의 정수를, 같으면 0을, 크면 양의 정수로 반환한다. 이 객체와 비교할 수 없는 타입의 객체가 주어지면 ClassCastException을 던진다. 다음 설명에서 sgn(표현식) 표기는 수학에서 말하는 부호 함수(signum function)를 뜻하며, 표현식의 값이 음수, 0, 양수일 때 -1, 0, 1을 반환하도록 정의했다.
|
· compareTo 메서드에서 필드와 값을 비교할 때 <, > 연산자는 쓰지 말아야 한다.
- 관계 연산자 <, >를 사용하는 방식은 오류를 유발한다. (부동 소수점 비교를 생각해보자)
- 대신 기본 타입 클래스가 제공하는 정적 compare 메서드나 Comparator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자.
출처
이펙티브자바 3판
'자바 > 이펙티브자바' 카테고리의 다른 글
| [Effective Java] 이펙티브자바 정리: 7장 람다와 스트림 (0) | 2022.02.07 |
|---|---|
| [Effective Java] 이펙티브자바 정리: 5장 제네릭 (0) | 2022.02.06 |
| [Effective Java] 이펙티브자바 정리: 4장 클래스와 인터페이스 (0) | 2022.01.27 |
| [Effective Java] 이펙티브자바 정리: 2장 객체 생성과 파괴 (0) | 2022.01.24 |
댓글