Comments on: Value objects: Immutability and Equality

By: Mark Needham

Mark Needham — Mon, 26 Oct 2009 21:36:07 +0000

@Ron – yeah sorry I should have mentioned that on the post.

The implementation did override those as well but I didn’t show the code for that bit cause it’s quite verbose! Good spot!

@alberto – we were able to access them because ‘obj’ refers to the class that we are currently in.

Thanks for the link to the post, looks interesting.

By: Ron

Ron — Mon, 26 Oct 2009 17:20:10 +0000

Should MyValueObject also override Equals(object) and GetHashCode()? Imagine a case where your MyValueObject gets cast to ‘object’ and then Equals gets called on it or it gets placed in a Dictionary. You would want your custom Equals(MyValueObject) to be called, right?

public override bool Equals(object obj)
{
if (obj is MyValueObject)
return Equals((MyValueObject)obj);
return false;
}

public override int GetHashCode()
{
return
otherValue.GetHashCode() ^
someValue.GetHashCode() ^
someOtherValue.GetHashCode();
}

By: alberto

alberto — Mon, 26 Oct 2009 16:17:31 +0000

You cannot access the fields of obj to do the comparison, they are private. http://grabbagoft.blogspot.com/2007/06/generic-value-object-equality.html is a good generic implementation.

By: Dave

Dave — Mon, 26 Oct 2009 13:22:10 +0000

Your solution works fine if you only have a few parameters. If you want to add more parameters you change the signature of the method. This then causes you to either refactor (if all the parameters are required) or to overload the constructor, whereas if you just passed in the object changes would be minimal. Maybe a better solution is to have a static method on your SomeMutableEntity to return your value object. In the end the situation is going to dictate what you are going to do.

By: DotNetShoutout

DotNetShoutout — Mon, 26 Oct 2009 12:18:39 +0000

Value objects: Immutability and Equality – Mark Needham…

Thank you for submitting this cool story – Trackback from DotNetShoutout…

By: Mark Needham

Mark Needham — Mon, 26 Oct 2009 10:45:21 +0000

@Chuck – yeah I guess if it had been called SomeMutableEntity in our code I probably wouldn’t have messed it up!

Thought I’d use that name just to make it obvious why the first solution doesn’t make sense.

By: Chuck

Chuck — Mon, 26 Oct 2009 10:35:25 +0000

Mark – I liked your final solution. Red Alerts rang out when SomeMutableEntity was passed in. You touched on it: the Client doesn’t really know that you are not (internally) using SomeMutableEntity for some additional processing (oh, and what Dave said).

Thanks for the post!

By: Reflective Perspective - Chris Alcock » The Morning Brew #462

Reflective Perspective - Chris Alcock » The Morning Brew #462 — Mon, 26 Oct 2009 08:41:23 +0000

[...] Value objects: Immutability and Equality – Mark Needham explores the concept of the value object and immutability of such objects with a real world example along with some techniques to work around some of the difficult parts of the implementation [...]

By: Leonardo Borges

Leonardo Borges — Sat, 24 Oct 2009 14:59:24 +0000

Hi Mark,
Yes you are correct. In Java I’d probably use the clone method like Chris mentioned.
Also, his point about collections is very well taken as it can lead to a false impression of immutability.

By: Chris Leishman

Chris Leishman — Sat, 24 Oct 2009 07:21:43 +0000

Note that this is _really_ commonly missed when dealing with collections. Although it’s still not perfect, I usually do this (in java):

public Constructor(final List entities) {
this.entities = new ArrayList(entities);
}

However, you often also have a getter for this list. So to be doubly sure nobody can modify the copy, I’d do:

public Constructor(final List entities) {
this.entities = Collections.unmodifiableList(new ArrayList(entities));
}