Representational Equality versus Value Equality

Question

I am coding a system where I have objects which represent a set of resources. These resources are identifiable (they have an ID). There can only be one resource with the same ID, and so multiple objects with the same ID really should have the same values.
My problem is with the equality concept in this case. Should it be based on the ID or on the values alone? Is object A = object B because they have the same ID OR should object A == object B because their fields are the same.

One possibility I was thinking of was to have the ID-based comparison be "equals" and the field-based comparison be "equivalent". Alternatively I could have it so the field-based comparison was "equals" and the ID based comparison was "representSameObject" (or something). Just a pseudo-code example:

class A {
   String uuid;
   int field1;
   double field2;
   List<String> listField;

   @Override
   public boolean equals(Object other) {
       return uuid.equals(other.uuid);
   }

   public boolean equivalent( other ) {
       if (this == other) {
           return true;
       }
       if (null == other) {
           return false;
       }
       if (other.getClass() != this.getClass()) {
           return false;
       }

       A rhs = (A) other;
       return new EqualsBuilder().append(field1, rhs.field1).append(field2, rhs.field2).append(listField, other.listField).isEquals();
   }
}

In the end this may come down to a personal preference coupled with system requirements, but I am very interested to learn how others have approached this concept. It has been annoying the heck our of me since I started on this project!

If it makes a difference I am programming at the minute in Java. I don't mind where the answer comes from though as this is obviously a conceptual issue.

Answer 1

One thing you can do is to look at how ORM frameworks, like Hibernate handle these situations. I believe by default 'domain objects' (objects that can be persisted) get an id as well as an equals() and hashCode() (that use the provided id for equivalence) by default.

They do suggest however that if you want to use these domain objects in collections, you should always override their provided equals() and hashCode() methods.

So maybe it's a matter of context. I believe that Hibernate uses the ids to see if it has a persisted object already. If the id is null, it will try to do an 'insert' versus if the id is not null, it will try to look up the persisted object and update its fields. If the id is not found, that is an error condition.

I hope this answer at least points you to some direction.

Answer 2

You should actually go one step further and consider it an error if there are two distinct objects that both represent the resource with ID X. This means that if you have two references to the object for ID X, then the two references should compare equal with the == operator (which compares reference equality in Java).

Allowing multiple objects to represent one and the same resource inevitably results in the objects becoming out-of-sync and bugs because different parts of the system having different, incompatible, views on the state of the resource.

Also, if you use the reference equality as a check for resource identity, then you could could use the equals method to check if two resources happen to have the same value at that moment.

Answer 3

If Bob is now wearing a blue hat instead of red hat (the one he was wearing yesterday) he is still Bob. So blue hat Bob equals red hat Bob.

I stick to keeping my equals to being identity based. Wether Bob has changed I keep in a different method or interface.