• Post Reply Bookmark Topic Watch Topic
  • New Topic

hashCode() for a subclass  RSS feed

 
Salman Ahmed
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Assuming that I have the following two classes defined:



and also assuming that I have valid (or reasonably implemented) versions of equals() and hashCode() for the super class Widget, how should I implement hashCode() for the Gadget subclass?

Also, is it considered bad "form" (or design) to have a sub-class that doesn't define any data members over and above the super class?

Thanks.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is nothing wrong with an extending class with no additional methods. It is might not be very useful with no changes, but there is nothing wrong with it. It is usual to override something in the subclass so you get some different behaviour. But if you have something like Car extends Vehicle and Van extends Vehicle, you can see there may be no need for additional fields beyond those common to all vehicles.

I don't like seeing lots of new methods in subclasses, and look what Rob Prime said about the Liskov Substitution Principle here, 2 days ago. But I know other people will have different opinions on this.

If you already have an good, overridden, equals method you can simply writein Gadget.

If you had no overridden equals method in the superclass (Widget) then it would default to the Object#equals() method which reads something likeAnd if you have no additional fields in Gadget over Widget, there is no need for a new hashCode method; it will return the same results for two objects which are "equal" provided it works correctly in Widget. Look at the API documentation for a few classes: 1 23 4 which are all in an inheritance hierarchy, and have not got any additional or overridden members. The only features you actually see in the documentation are their overloaded constructors.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree with Campbell - in this case super.equals(other) implies that getClass() == other.getClass(). Therefore it can be omitted, and all that remains is actually super.equals(other). The entire equals method can be omitted.

Should you remove the call to super.equals(other), then you will need to create a hashCode method that uses the fields you compare on. Since you only compare on the class objects the hashCode method should use that one too:

You do realize that all instances of that class would be equal to each other this way?
 
Salman Ahmed
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I implement the equals() and hashCode() methods for class Gadget as:



then I do not have the issue of all Gadgets being equal or of having the same hash code value.

However, is there any problem or issue in using the class type in the equals() method but NOT using it in the hashCode() method?

Canonically speaking, is there any requirement to compute the hashCode based on the same comparisons that are done in the equals() method?

The code as it is above seems to work well for me!


Thanks.
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You need to go back to the Object class and read it carefully, but as far as I remember you ought to take every field into consideration for the hashcode which is used in the equals method. I sometimes add the className.hashCode() to my hashcodes, but that is not compulsory.
Remember you have to return the same hashcode if two objects return true from equals, but you cannot guarantee to return different hashcodes from two objects returning false from equals.
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Not all fields are necessary, but the fields in hashCode() is usually (should be?) a subset of the fields in equals():

Since equality means the field2 values are equal, hashCode will also be the same.

Of course subset can mean an empty set:

Perfectly legal, but with poor performance in hashing maps and collections.
 
Salman Ahmed
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the info guys!
Regards,
 
Campbell Ritchie
Marshal
Posts: 56595
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're welcome
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!