Timeline for subclass of immutable object not immutable, can this work?

5 events

when toggle format	what		by	license	comment
May 10, 2013 at 20:54	vote	accept	dsollen
May 10, 2013 at 19:19	comment	added	Caleb		If your model assumes that the objects are immutable, then there's really no problem -- it's not going to try to change them. What I was trying to get across above is that you want to avoid having those objects change when the model (or anything else) doesn't expect them to. So, if some method in your model advertises that it returns an immutable object, clients of the model shouldn't test the objects to see if maybe they're really mutable after all, and change them if they are. I can't speak to your overrides -- it really just comes down to when you want to consider two objects equal.
May 10, 2013 at 18:56	comment	added	dsollen		Thank you for this, but just to clarify a little. My Model does essentially assume that the children are immutable, as it uses them in sets, hashmaps etc. My work around is to not override the equals/hashcode methods; so that the 'immutable parts' are the only parts used for equal and hash. Is this still something you would call acceptable? I'm maintaining the 'important part' of the immutability assumed below essentially.
May 9, 2013 at 23:41	history	edited	Robert Harvey	CC BY-SA 3.0	added 12 characters in body
May 9, 2013 at 23:21	history	answered	Caleb	CC BY-SA 3.0