Mutable Objects having equals method

[Yadu]

Program Development in Java by Barabara Liskov mentions that "mutable Objects in Java shouldn't implement equals method" Chapter 5, sidebar 5.1. But many of Java's Collection like Vector which are mutable and implement equals method for comparing state (elements) rather than relying on reference equals. Can someone shed light on the anomaly

yadu

[Fubarable]

I'm not sure I see the paradox here. The text is saying that [b]im[b]mutable objects shouldn't implement equals and you're showing an example of a mutable class implementing equals which all makes sense.

[Norm]

Does the author give a reason for the statement?
String is immutable and its equals() method is THE way to compare Strings.

[Fubarable]

delete: in error

[Yadu]

The subject was right, but text had typo..mutable shouldnt implement equals, only immutables should implement equals....STring is immutable and implements equals that is correct, Vector is mutable and ishould rely of reference equals mplments equals...that is the paradox

[Yadu]

I dont understand the message, i didnt post this anywhere...have just a quesion

[Yadu]

I think the answer lies in this Java Specification
"For mutable objects, the answer is not always so clear. Should equals() and hashCode() be based on the object's identity (like the default implementation) or the object's state (like Integer and String)? There's no easy answer -- it depends on the intended use of the class. For containers like List and Map, one could have made a reasonable argument either way. Most classes in the Java class library, including container classes, err on the side of providing an equals() and hashCode() implementation based on the object state"

[Fubarable]

I dont understand the message, i didnt post this anywhere...have just a quesion

You are correct and I don't know what I was thinking. I'm terribly sorry for the mix up.

[JosAH]

Suppose you stick a mutable object in a collection that relies on the equals( ... ) method and/or the hashCode() method of the object. The object is mutable so you can change its state behind the back of the collection and so you mess up the bookkeeping of the collection in a most horrible way.

OTOH not implementing those methods for your mutable object reduces the flexibility of it all so for aesthetic reasons you shouldn't implement them but for practical reasons you should do so ...

kind regards,

Jos

[Norm]

The object is mutable so you can change its state behind the back of the collection and so you mess up the bookkeeping of the collection

Sounds like collections should have change listeners. Or the user should call the collection with a validate like method.

[JosAH]

Sounds like collections should have change listeners. Or the user should call the collection with a validate like method.

That'd involve more code: each mutable object should be a source of events (and all the add and remove listeners stuff) and the collections should register themselves whenever an object is added to them. IMHO knowing what you're doing can be just as effective ;-) imho protecting code to just stupidity is the next generation of 'defensive programming' and that habit has just bloated a lot of code ...

kind regards,

Jos