3. Methods Common to All Objects

모든 오브젝트에 통용되는 메소드를 알아보자.

10. Obey the general contract when overriding equals.

클래스 내 각 인스턴스가 본질적으로 유일하거나, 논리적 동일성 테스트를 제공할 필요가 없거나, 상위 클래스가 equals를 이미 오버라이드했거나, 클래스가 private/package-private고 equals가 불릴 일이 없다면, equals를 오버라이드하지 마라. 오버라이드한다면, 동치 관계의 규칙을 지켜야 한다. 그 규칙을 깨면 다른 오브젝트가 해당 클래스에 어떻게 동작할지 예측할 수 없어진다. 인스턴스화 가능한 클래스에 대해선 equals 규칙을 보존하면서 value 컴포넌트를 추가하도록 확장할 수는 없다. 또한 equals는 일관성도 보장해야 하며, 신뢰할 수 없는 리소스에 의존하는 equals 메소드는 쓰지 마라. 인자가 이 오브젝트에 대한 참조인지 체크하려면 == 연산자를 써라. 인자가 맞는 타입을 가졌는지 체크하려면 instanceof를 써라. 올바른 타입으로 캐스팅해라. 클래스 내 각 유의미한 필드에 대해, 인자의 그 필드가 이 오브젝트의 해당 필드에 매치되는지 체크하라. equals 메소드를 쓰고 난 뒤에는 동치 관계에 대해 체크하라. hashCode를 항상 같이 구현하고, 너무 복잡하게 생각하지 마라. equals 선언에 Object 말고 다른 타입을 쓰지 마라.

11. Always override hashCode when you override equals.

equals를 오버라이드하는 모든 클래스는 hashCode도 오버라이드해야 한다. 같은 오브젝트는 같은 hashCode를 가져야 하기 때문이다. 해시 코드 계산할 때 성능을 개선하겠다고 주요 필드를 제외하지 마라. hashCode에 의해 반환되는 값에 대해 상세한 명세를 제공해 클라이언트가 그에 의존하게 하지 마라. 그러지 않는 것이 유연성을 준다.

12. Always override toString.

좋은 toString 구현을 제공하는 것은 클래스를 훨씬 더 쓰기 편하게 하고 시스템이 더 디버깅하기 쉽게 한다. 실용적으로는 toString 메소드는 오브젝트에 담긴 모든 흥미로운 정보를 반환해야 한다. 포맷을 특정하건 하지 않건, 이에 대해서 분명하게 문서화해야 한다. toString으로 반환되는 값에 담긴 정보에 대한 체계적 접근을 제공하라.

13. Override clone judiciously.

Cloneable 을 구현하는 클래스는 적절하게 동작하는 public clone 메소드를 제공하도록 예측받는다. immutable 클래스는 절대 clone 메소드를 제공하면 안 된다. clone 메소드는 생성자같은 효과를 갖는다. 이는 clone의 불변 조건을 만족해야 하며 원본 오브젝트에 해를 끼치면 안 된다. Cloneable 아키텍처는 mutable 오브젝트를 가리키는 final 필드의 일반적인 사용례와는 맞지 않는다. public clone 메소드는 throws 절을 생략해야 한다. 사실 오브젝트 복제에 대한 더 나은 접근법은 복사 생성자나 복사 팩토리를 제공하는 것이다.

14. Consider implementing Comparable.

compareTo 메소드에서 <와 > 연산자를 쓰는 것은 번잡하고 에러에 취약하며 추천되지 않는다.