<aside> 💡 *equals 메서드는 재정의하기 쉬워 보이지만, 자칫하면 끔찍한 결과를 초래한다!*

</aside>

• 문제를 회피하는 가장 쉬운 길은 아예 재정의하지 않는 것이다.
  • 그냥 두면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다.

아래의 상황 중 하나에 해당된다면, 재정의하지 않는 것이 최선이다.

1. 각 인스턴스가 본질적으로 고유하다.

• 값을 표현하는 게 아니라, 동작하는 개체를 표현하는 클래스가 여기 해당한다.
  • ex) Thread

1. 인스턴스의 논리적 동치성(logical equality)을 검사할 일이 없다.

• ex) java.util.regex.Pattern 은 equals 를 재정의해서 두 Pattern 의 인스턴스가 같은 정규표현식을 나타내는지를 검사하는 방법도 있다.
  • 하지만, 설계자가 클라이언트가 애초에 필요하지 않다고 판단했다면, Object 의 기본 equals 만으로 해결된다.

1. 상위 클래스에서 재정의한 equals 가 하위 클래스에도 딱 들어맞는다.

• ex) Set 구현체에는 AbstractSet 이 구현한 equals 를 상속받아 쓴다.
  • List 구현체들은 AbstractList , Map 구현체들은 AbstractMap 으로부터 상속받아 그대로 쓴다.

1. 클래스가 private 이거나 package-private 이고 equals 메서드를 호출할 일이 없다.

• 실수로라도 호출되는 걸 막고 싶다면, 다음과 같이 구현해두자.

@Override
public boolean equals(final Object o) {
		throw new AssertionError(); // 호출 금지!
}

그렇다면 언제 equals 를 재정의해야 할까?

→ 두 객체가 물리적으로 같은지가 아닌 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals 가 논리적 동치성을 비교하도록 재정의되지 않았을 때!