3-1 Equals와 toString의 재정의

# 어떨 때 Equals 메서드를 재정의 해야 할까?

사실 아래와 같은 상황에서는 굳이 재정의 할 필요가 없다.

• 각각의 객체가 고유하다.
  ➡ 값(value) 대신 고유한 활성 개체(active entity)를 나타내는 Thread 같은 클래스도 마찬가지.
• 클래스에 "논리적 동일성(logical equality)"을 검사해야할 필요성이 없다. 
  ➡ 일례로 java.util.Random 클래스는 두 Random 객체가 같은 난수를 만드는지 Equals로 검사할 일이 없다.
• 상위 클래스에서 재정의한 equals가 있다면 하위 클래스에서 사용하기에도 적당하다.
• 클래스가 package-private로 선언되어있다면 equals 메서드를 호출할 일이 없다.

 

다음과 같을 때에는 재정의 하는게 바람직하다.

• 객체 동일성(object equality)이 아닌 논리적 동일성, 동등성(logical equality)의 개념을 지원하는 클래스일 때
• 상위 클래스의 equals가 하위 클래스의 필요를 충족하지 못할 때

 

# 두 객체가 논리적으로 같다는건 무슨 의미일까?

• ✔반사성(reflexive): 참조 x가 있을 때, x.equals(x)는 true를 반환한다. 모든 객체는 자기 자신과 같아야 한다.
• ✔대칭성(symmetric): 참조 x와 y가 있을 때, 두 비교문 x.equals(y)와 y.equals(x)의 값은 같아야 한다.
• ✔추이성(transitive): 참조 x, y, z가 있을 때, x.equals(y)가 true이고 y.equals(z)가 true이면 x.equals(z)도 true이다.
• ✔일관성(consistent): null 아닌 참조 x와 y가 있을 때, equals를 통해 비교되는 정보에 아무 변화가 없다면, x.equals(y) 호출 결과는 호출 횟수, 시간에 상관없이 항상 같아야 한다. 신뢰성이 없다면 equal를 재정의 하지말자,
• ✔널(Null)에 대한 비 동치성(Non-nullity): null 아닌 참조 x에 대해서, x.equals(null)은 항상 false이다.

 

# 주의해야할 점

• 당연한거지만 equals 메서드의 인자를 Object의 원형이 아닌 다른 것으로 바꾸지마라.
• equals()를 재정의 했다면 자바의 클래스 규약에 따라 반드시 hashCode()도 재정의하라.
  ➡ Collection등 많은 프레임워크에서는 객체의 고유값인 hashCode를 먼저 비교하여 비교 성능을 최적화 시킨다.
  다만 반대의 경우, 즉 equals(Object)가 다르다고 해서 두 객체의 hashCode의 값이 꼭 다를 필요는 없다.
  

그럴일은 없겠지만. 성능을 높인답시고 hashCode를 비교할 객체의 핵심필드를 사용하지 않고 고유한 숫자값으로 대충 만들었다간, 해시테이블 사용시 해시 품질이 나빠져 성능을 떨어뜨릴 수 있다.

2021.07.27 - [기본 지식/Java 기본지식] - .equals와 .hashCode()는 항상 함께 오버라이딩해야한다.

.equals와 .hashCode()는 항상 함께 오버라이딩해야한다.

 

 

# toString을 항상 재정의하라

toString은 자바 규약에서도 "사람이 읽기 쉽도록 간략하지만 유용한 정보를 제공해야한다"고 명시되어있다.

Object의 기본 toString은 객체의 검증된 풀네임 (Jenny=PhoneNumber@163b91)을 반환한다. 가능하다면 toString 메서드는 객체 내의 중요한 정보를 담아 반환하도록 변경하도록 하자.