Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Agile forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

why not overload equals ?

 
Zambian Enquirer
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello All,
I understand that overloading, as opposed to overriding, equals is poor form.
Can someone explain what the problems are with overloading equals?
Thanks,
Zambian Moose
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Zambian,
I assume you mean defined in Object. The only thing I see wrong with overloading the equals method is that it is non-standard. If you have a good reason for having overloaded equals methods then do it.
Hope this helps,
Michael Morris
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The following example illustrates a possible reason for overridding, rather than just overloading:
Say you have a class A and you provide a method

This means you can only compare an A object with another A object. If you only have an Object reference, such as that returned from a Container, then you have to cast it before you call this version of equals(). If you simply override equals(), rather than overload it, the casting occurs inside the method, and you can compare an A object with an object of any other class.
Also, I think Vector and other Containers only deal with Object references, so they need equals() to be overridden, rather than overloaded.
In conclusion, there is nothing in the language stopping you from overloading equals(), however, it can complicate your code and even break the container classes.
Layne
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OTOH, I think there is nothing wrong with *both* overloading and overriding equals:
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Seconding Ilja. This is the way I usually write equals():I personally think it is very readable, but it confused the heck out of one fellow developer who thought for a moment that the word "that" was another Java keyword, in addition to "this"
There is a small performance advantage:will directly call equals(Foo) and execute without cast.
- Peter
 
Zambian Enquirer
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
write equals():I personally think it is very readable,
Thank you all for your replies.
I like this style of coding it! Neat.
Would someone like to elaborate on how overloading equals could break container classes?
I think I may have found one answer to my question here:
http://csis.pace.edu/~bergin/Java/OOJavaFAQ.html
If you overload equals you will have two different equals methods in your class. However, the compiler and libraries know about the inherited one and call it from a number of places--the HashMap add method, for example. You have to realize that these calls will still go to the inherited method and not to the overloaded one. If you want to write a method to check equality of objects rather than depend on the default behavior of the inherited equals method (reference equality), then you need to override equals, NOT overload it.
This seems to tie in with advice I have seen that one must also override hashCode when overriding equals.
Zambian
 
Zambian Enquirer
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
write equals():I personally think it is very readable,
Thank you all for your replies.
I like this style of coding it! Neat.
Would someone like to elaborate on how overloading equals could break container classes?
I think I may have found one answer to my question here:
http://csis.pace.edu/~bergin/Java/OOJavaFAQ.html
If you overload equals you will have two different equals methods in your class. However, the compiler and libraries know about the inherited one and call it from a number of places--the HashMap add method, for example. You have to realize that these calls will still go to the inherited method and not to the overloaded one. If you want to write a method to check equality of objects rather than depend on the default behavior of the inherited equals method (reference equality), then you need to override equals, NOT overload it.
This seems to tie in with advice I have seen that one must also override hashCode when overriding equals.
Zambian
 
JD Glanville
Greenhorn
Posts: 22
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I only have one suggestion to make to your original code, which read like this:


My suggestion is to include appropriate null pointer checks, and for pointer equality (pointer equality for minor performance increase):

The null pointer check will make your code more robust (by preventing an unnecessary null pointer exception). The pointer check (this == that) will short-circit the attribute-wise commparison, as they're in the same memory space, therefore they must be equal.
Just my two cents.
 
stephan schweitzer
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i think it is very dangerous to override the equals-method. at least if you have subclasses. example:

If you now have the following code:

The method called by this statement is the "public boolean equals(A a)"-method of "A" and not the "public boolean equals(Object o)"-method of
"B" which should have been called. Two solutions to this problem
Solution 1:
Add a "public boolean equals(A a)"-method to B and all other subclasses.
This will result in an explosion of equals-methods.
Solution 2:
Do not override equals.
I prefer the second solution.
Stephan
[ October 29, 2003: Message edited by: stephan schweitzer ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic