10. equals는 일반 규약을 지켜 재정의하라

equals 메서드는 재정의하기 쉬워 보이지만 곳곳에 함정이 있어 자칫하면 끔찍한 결과를 초래한다.

문제를 회피하는 가장 쉬운 길은 아예 재정의하지 않는 것이다.

그냥 두면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다.

다음에서 열거한 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선이다

• 각 인스턴스가 본질적으로 고유하다.
• 인스턴스의 논리적 동치성을 검사할 일이 없다.
  • 논리적 동치성 : 객체 말고 값이 같은지 비교하는
• 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다.
• 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다.

그럼 equals를 재정의해야 할 때는 언제일까?? 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지 않았을 때다.

주로 값 클래스가 여기 해당한다.

11. equals를 재정의하려거든 hashCode도 재정의하라

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다.

hashCode 재정의를 잘못했을 때 크게 문제가 되는 조항은 “논리적으로 같은 객체는 같은 해쉬코드를 반환해야 한다” 이다.

12. toString을 항상 재정의하라

Object의 기본 toString 메서드가 우리가 작성할 클래스에 적합한 문자열을 반환하는 경우는 거의 없다.

equals와 hashCode만큼 대단히 중요하진 않지만, toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다.

13. clone 재정의는 주의해서 진행하라

Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스지만, 아쉽게도 의도한 목적을 제대로 이루지 못했다.

가장 큰 문제는 clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이고, 그 마저도 protected라 데 있다.