467
333
| |
add comment |
508
| The theory (for the language lawyers and the mathematically inclined):equals() (javadoc) must define an equality relation (it must be reflexive, symmetric, and transitive). In addition, it must be consistent (if the objects are not modified, then it must keep returning the same value). Furthermore, o.equals(null) must always return false.hashCode() (javadoc) must also be consistent (if the object is not modified in terms of equals() , it must keep returning the same value).
The relation between the two methods is:
Whenever
a.equals(b) , then a.hashCode() must be same as b.hashCode() .In practice:
If you override one, then you should override the other.
Use the same set of fields that you use to compute
equals() to compute hashCode() .
Use the excellent helper classes EqualsBuilder and HashCodeBuilder from the Apache Commons Langlibrary. An example:
Also remember:
When using a hash-based Collection or Map such as HashSet, LinkedHashSet, HashMap, Hashtable, orWeakHashMap, make sure that the hashCode() of the key objects that you put into the collection never changes while the object is in the collection. The bulletproof way to ensure this is to make your keys immutable, which has also other benefits.
| ||||||||||||||||||||
|
151
|
There are some issues worth noticing if you're dealing with classes that are persisted using an Object-Relationship Mapper (ORM) like Hibernate. If you didn't think this was unreasonably complicated already!
Lazy loaded objects are subclasses
If your objects are persisted using an ORM, in many cases you will be dealing with dynamic proxies to avoid loading object too early from the data store. These proxies are implemented as subclasses of your own class. This means that
this.getClass() == o.getClass() will return false. For example:
If you're dealing with an ORM using
o instanceof Person is the only thing that will behave correctly.
Lazy loaded objects have null-fields
ORMs usually use the getters to force loading of lazy loaded objects. This means that
person.name will be null if person is lazy loaded, even if person.getName() forces loading and returns "John Doe". In my experience, this crops up more often in hashCode and equals .
If you're dealing with an ORM, make sure to always use getters, and never field references in
hashCode and equals .
Saving an object will change it's state
Persistent objects often use a
id field to hold the key of the object. This field will be automatically updated when an object is first saved. Don't use an id field in hashCode . But you can use it inequals .
A pattern I often use is
But: You cannot include
getId() in hashCode() . If you do, when an object is persisted, it'shashCode changes. If the object is in a HashSet , you'll "never" find it again.
In my
Person example, I probably would use getName() for hashCode and getId plusgetName() (just for paranoia) for equals . It's okay if there are some risk of "collisions" forhashCode , but never okay for equals .hashCode should use the non-changing subset of properties from equals | ||||||||
|
82
|
If you are using Eclipse it has integrated a very cool
hashCode() / equals() generator.
You just have to be on a class and do: right click > Source code > Generate hashCode() and
equals() ...
Then, a window will show up and you can choose the fields to include in your methods.
| ||||||||||||
|