• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Why are we encouraged to override methods from Object?

 
James Elsey
Ranch Hand
Posts: 228
Android IntelliJ IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Its come up a few times in Head First Java, it mentions that we should ALWAYS override toString and equals.

I can't think of any reason why I would need to, what is wrong with using Object.equals? I can't see how I could override, and provide my own implementation better than what is already there :S
 
Rob Spoor
Sheriff
Pie
Posts: 20659
64
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Object.equals uses ==, and nothing else. Sometimes you want to override that. A good example is String. Imagine not being able to tell if two different String objects contain the same characters!

As for toString(), I really can't see much use in com.javaranch.Person@123456. I'd much rather prefer com.javaranch.Person[name=Rob,role=bartender,status=awesome]. It tells you much more.

Keep in mind that equals has a partner in crime - hashCode. Make sure to always follow the rules specified in the Javadoc of both methods if you override at least one of them.
 
James Elsey
Ranch Hand
Posts: 228
Android IntelliJ IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Nice explanation, thanks Rob ;)
 
David Newton
Author
Rancher
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
(I also include the default toString in my own implementations, as I often need to know if objects are the exact same instance, which I can't always tell from instance data.)
 
Campbell Ritchie
Sheriff
Pie
Posts: 50171
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Rob Prime wrote: . . . com.javaranch.Person[name=Rob,role=bartender,status=awesome]. It tells you much more. . . .
 
Avishkar Nikale
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The plain Object methods need to be overridden for following reasons

1) toString() - For a string representation of your Class instance
2) equals() & hashCode() - For determining uniqueness of your Class instance
so that you can use them for comparisons, in collections etc
3) clone() - So that you can create replicas of your Class instance
or to prevent the same in some cases.
4) finalize() - to perform cleanup actions before the Class instance is garbage collected

You can study the java.lang.Object API
for detailed information.

 
Campbell Ritchie
Sheriff
Pie
Posts: 50171
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Avishkar Nikale wrote: . . .
2) equals() & hashCode() - For determining uniqueness . . .
Not uniqueness, but identity. You can have two objects which have the same state, and they can return true from equals(). Remember to override both those method.
3) clone() - So that you can create replicas of your Class instance
or to prevent the same in some cases.
More commonly prevent. Remember you must implement the Cloneable interface, otherwise clone() won't work.
4) finalize() - to perform cleanup actions before the Class instance is garbage collected
That is rarely necessary: anybody posting questions on "beginning Java" will never need finalize().
You can study the java.lang.Object API
for detailed information.
Also, Google for Joshua Bloch's Effective Java™; there used to be a sample chapter from the 1st edition available free of charge on the net, which describes those methods.

There are also getClass(), notify(), notifyAll() and three wait() methods which you don't usually override. In fact, I think they are final, so you can't override them.
 
Avishkar Nikale
Ranch Hand
Posts: 173
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Campbell for detailing my summary & correcting where required.

James,

We hope to have at least lead you to a path of understanding why to override Object methods.




 
Campbell Ritchie
Sheriff
Pie
Posts: 50171
79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Avishkar Nikale wrote:Thanks . . .
 
Rob Spoor
Sheriff
Pie
Posts: 20659
64
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Campbell Ritchie wrote:There are also getClass(), notify(), notifyAll() and three wait() methods which you don't usually override. In fact, I think they are final, so you can't override them.

They are indeed final.
 
Pratik D mehta
Ranch Hand
Posts: 121
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Very nice explanation. Got things cleared in my mind also . Thank you all .
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic