An entity has identity, which implies there should only be one object (e.g. a particular customer) in memory.
As such, reference equality (which is what the base version of object.equals checks for) should be the only equality we care about.
A value object on the other hand would need to overrride Equals as there may be many in memory.
Are there any issues with the above reasoning?
I just can’t imagine why I would have two customer objects representing the same customer, and in any case where I did (e.g. took a clone to do something with it), I can’t think of any circumstances where I would need to check if it was equal to the orginal object.
Even in a distributed environment, any client process should only contain one object for a certain customer.
1
I just can’t imagine why I would have two customer objects representing the same customer, and in any case where I did (e.g. took a clone to do something with it), I can’t think of any circumstances where I would need to check if it was equal to the orginal object.
This can easily happen: You read a list of objects from somewhere (e.g., from the database) and receive one object from elsewhere (e.g., from a web request). Now you don’t call equals, you look up the object in the list, so equals gets called anyway.
That’s where a field based equals makes sense. However, selecting the fields which should participate in the checks is something between hard and impossible. Consider class Person, what business property never changes? Name? Surely not. SSN? Neither.
That’s why many prefer an ID-based equality. This has other problems, e.g., assigning the ID to newly created objects and some others. There’s lengthy discussion about it somewhere on Hibernate pages.
Not defining equals is a way I’ve never heard about.
Even in a distributed environment, any client process should only contain one object for a certain customer.
What if one process sends an entity to another one?
3
I just can’t imagine why I would have two customer objects
representing the same customer
Not all objects represent “customers”. Other objects represent other kind of entities. In those cases a value equality could be more or less useful according to bussines rules, allowing to be able to check whether or not a given object passed as a parameter is already (business-based) in a given collection.
Even in a distributed environment, any client process should only contain one object for a certain customer.
Distributed systems are not centralized. They are the opposite of centralized. They interoperate sending objects back and forth. A value equality helps in such interoperability since, being distributed, memory location addresses wouldn’t match. Also how would you prevent independent, distributed processes from instantiating objects that are the same according to a business rule ?
Again, not all objects are customers and your question is about “entities”. Maybe you should rename your question to “Is there any reason to override equeals for a customer class?”
Another issue.
According to your reasoning two separate customer objects, with identical state ( values ) would be different customers since they will have different memory addresses (variable references).
Never assume your inability to imagine why someone would WANT to do something has any correlation as to what someone else WILL do.
Remember Murphy’s Law, and ask “is there ANY situation where not being able to recognize distinct objects as equal will cause problems”. If the answer is yes, the few lines of code needed to compare equality by value will be worthwhile.