Joshua Bloch

equal objects must have equal hash codes.

well-designed component hides all its implementation details, cleanly separating its API from its implementation. Components then communicate only through their APIs and are oblivious to each others’ inner workings. This concept, known as information hiding or encapsulation

the equality test imposed by the compareTo method should generally return the same results as the equals method

Use of the relational operators < and > in compareTo methods is verbose and error-prone and no longer recommended.

The rule of thumb is simple: make each class or member as inaccessible as possible.

a method overrides a superclass method, it cannot have a more restrictive access level in the subclass than in the superclass

Note that a nonzero-length array is always mutable, so it is wrong for a class to have a public static final array field, or an accessor that returns such a field.

The Boolean.valueOf(boolean) method illustrates this technique: it never creates an object. This technique is similar to the Flyweight pattern [Gamma95]. It can greatly improve performance if equivalent objects are requested often, especially if they are expensive to create.

when is it appropriate to override equals? It is when a class has a notion of logical equality that differs from mere object identity and a superclass has not already overridden equals.

providing a good toString implementation makes your class much more pleasant to use and makes systems using the class easier to debug.