Chapter 3. Methods Common to All Objects
Item 7: Obey the general contract when overriding equals
This is the right thing to do if any of the following conditions apply:
a) Each instance of the class is inherently unique.
b) You don't care whether the class provides a "logical equality" test.
c) A superclass has already overridden equals, and the behaviour inherited from the superclass is appropriate for this class.
d) The class is private or package-private, and you are certain that its equals method will never be invoked.
Here's a recipe for a high-quality equals method:
1) Use the == operator to check if the argument is a reference to this object.
2) Use the instanceof operator to check if the argument is of the correct type.
3) Cast the argument to the correct type.
4)
For each "significant" field in the class, check to see if that field
of the argument matches the corresponding field of this object.
5)
When you are finished writing your equals method, ask yourself three
questions: Is it symmetric, is it transitive, and is it consistent?
Here are a few final caveats:
a) Always override hashCode when you override equals.
b) Don't try to be too clever.
c) Don't write an equals method that relies on unreliable resources.
d) Don't substitute another type for Object in the equals declaration.
Item 8: Always override hashCode when you override equalsYou must override hashCode in every class that overrides equals.
The key provision that is violated when you fail to override hashCode is the second one:
Equal objects must have equal hash codes.
Here is a simple recipe:
1. Store some constant nonzero value, say 17, in an int variable called result.
2. For each significant field f in your object (each field taken into account by the equals method, that is), do the following:
a. Compute an int hash code c for the field:
i. If the field is a boolean, compute (f ? 0 : 1).
ii. If the field is a byte, char, short, or int, compute (int)f.
iii. If the field is a long, compute (int)(f ^ (f >>> 32)).
iv. If the field is a float compute Float.floatToIntBits(f).
v. If the field is a double, compute Double.doubleToLongBits(f), and then hash the resulting long as in step 2.a.iii.
vi.
If the field is an object reference and this class's equals method
compares the field by recursively invoking equals, recursively invoke
hashCode on the field. If a more complex comparison is required,
compute a "canonical representation" for this field and invoke hashCode
on the canonical representation. If the value of the field is null,
return 0 (or some other constant, but 0 is traditional).
vii.
If the field is an array, treat it as if each element were a separate
field. That is, compute a hash code for each significant element by
applying these rules recursively, and combine these values as described
in step 2.b.
b. Combine the hash code c computed in step a into result as follows: result = 37*result + c;
3. Return result.
4. When you are done writing the hashCode method, ask yourself whether equal
instances have equal hash codes. If not, figure out why and fix the problem
Do not be tempted to exclude significant parts of an object from the hash code computation to improve performance.
Item 9: Always override toStringProviding a good toString implementation makes your class much more pleasant to use.
When practical, the toString method should return all of the interesting information contained in the object.
Whether or not you decide to specify the format, you should clearly document your intentions.
It is always a good idea to provide programmatic access to all of the information contained in the value returned by toString.
Item 10: Override clone judiciouslyIf you override the clone method in a nonfinal class, you should return an object obtained by invoking super.clone.
In practice, a class the implements Cloneable is expected to provide a properly functioning public clone method.
public Object clone() 
{
try {
return super.clone();
} catch(CloneNotSupportedException e) {
throw new Error("Assertion failure"); // Can't happen
}
}If, however, your object contains fields that refer to mutable objects, using this clone
implementation can be disastrous. Neglect the rest, refer to the book for more details...
Item 11: Consider implementing Comparable
The compareTo method is not declared in Object. Rather, it is the sole method in the java.lang.Comparable interface.
Array
element comparisons of Chapter 11: Collections of Objects in
<<Thinking in Java>> 3rd ed. Revision 4.0, has a more
practical way to explain this.