Re: hashCode() for Custom classes
sasuke wrote:
Hello to all Java programmers out there.
I am currently faced with the task of providing a logical equals()
method for my domain / business classes. This job being done, I now
have to override the hashCode() so that when an object of this class
is used as a key in a Map, the Map behavior is well defined.
I have thought of a couple of ways to do this but would like to give
inputs on my thoughts:
public class Agent {
String name;
String code;
Address addr;
/**
* The hash code of Agent is the combined hash code of
* it's constituent elements.
*/
public int hashCode() {
return(name.hashCode() +
code.hashCode() +
addr.hashCode());
}
This is all right, assuming that the name, code, and
addr fields are used in the equals() determination. As
Peter Duniho points out, there are ways to combine the
three pieces that "spread the bits" better.
/**
* The hash code of Agent is the hash code of the
* string representation of it's constituent elements.
* THis is guaranteed to be unique since the string
* representation of no objects is the same unless they
* actually are equal. This approach might also benefit
* from the fact that Strings in case of Java are pooled
* so a hashCode string once calculated for an object will
* remain for it's lifetime in the string pool
*/
public int hashCode() {
return((name + code + addr).toString().hashCode());
}
}
This is very bad, because it assumes that the toString()
method of the Address class produces nothing but characters
that are involved in its equals() method. Or, turning it
around, it assumes that toString() produces no characters
that are influenced by anything equals() doesn't consider.
(Also, it means that either Address or its toString() must
be final so they can't be overridden in a subclass that might
violate the assumption.)
The rule -- maybe I should say THE RULE -- is that equals()
and hashCode() must agree. If objA.equals(objB) is true, then
it MUST be the case that objA.hashCode() == objB.hashCode(),
which implies that the hashCode() value MUST NOT depend on any
piece of data that doesn't affect the equals() method. (If
it did, then an objA and objB that differed only in that datum
would be equal but would have different hashCodes, violating
THE RULE.)
Which approach would be better? The one utilizing the nested calls to
the hashCode() of constituent elements or the String approach? Also
how would I prove whether the hashCode() algorithm chosen by me will
in all cases generate unique hash codes?
It is usually impossible to guarantee unique hashCode()
values, because hashCode() returns an int and there are "only"
four billion ints. Four billion may sound like a lot, but
consider: How many different Strings exist? Let's see: there's
one empty String, 64K one-character Strings, 4G two-character
Strings, 256T three-character Strings, ... There are clearly
a *lot* more Strings than there are int values, so there aren't
enough unique ints to go 'round.
--
Eric.Sosman@sun.com