It has been proposed that ValueObject''''''s should be immutable in order to avoid the aliasing problems that would occur if two objects held references to a single, mutable, instance of a value object. Recall that ValueObject''''''s derive their identity from their state. As a result changing the state of a ValueObject is tantamount to changing its identity out from under its reference. Changing the state of a ValueObject that is held by reference by two different objects effectively changes the identity of both of the objects so held even when the intent is generally to change only one. Making value objects immutable solves this problem by forcing the developer to create a new object every time some aspect of the ValueObject's state changes. This is certainly a viable solution but it is not the only one available. 

Another solution to the same problem is to hold ValueObject''''''s, not by reference, but by value. This comes naturally in a language such as C++ where the distinction between values and references is explicit. If two objects hold the same ValueObject by value it means that there are two separate instances of the same state and that changing state of one instance is not tantamount to changing the state of the other. This solution trades the convenience of holding all objects by reference for the convenience of being able to change any aspect of a ValueObject's state without having to create an entirely new object to do so. It is generally implemented by defining a copy constructor and an assignment operator that copy the state of one ValueObject over to another and one or more comparison operators (==, !=, >, <, >= and <=) that compare the state of one ValueObject to another. This strategy has the happy side effect of allowing aliasing when it is desired simply by holding ValueObject-s by reference instead of by value.

The lack of garbage collection in C++ makes the immutable ValueObject strategy somewhat more inconvenient so it is seldom seen in that language in its pure form. However, the existence of constant references in C++ does allow for a compelling combination of these two strategies. With this strategy ValueObject parameters and return values are passed by constant reference. These local variables are references to immutable ValueObject''''''s and have the same properties as described in ValueObjectsShouldBeImmutable. However, member variables are typically held by value. When one of these constant references is assigned to a member variable the state of the object that it refers to is copied into the member variable thereby allowing the member variable to change without causing aliasing problems between it and the referred-to object.

On the ValueObject page DirkRiehle makes reference to a strategy that involved a combination of reference-counting and copy-on-write semantics. In this scheme reference-counting replaces garbage-collection and is specific to C++. The implementation of copy-on-write semantics, however, is applicable to multiple languages and provides a portable strategy for allowing ValueObject-s to be mutable (or at least appear to be mutable). It can be thought of as automating the process of creating a new instance whenever the state of the ValueObject changes so that clients don't have to remember to do it themselves. To accomplish this a reference to an immutable ValueObject is held by the mutable ValueObject. All non-mutating calls are simply forwarded to the immutable ValueObject. Mutating calls are intercepted and implemented by creating a new immutable ValueObject with the correct new state. Instances of the mutable ValueObject must be passed by value (in Java that means making a copy through "clone" in C++ it just means not passing by pointer or reference) to avoid aliasing problems. Since the only member of the mutable ValueObject is a reference this is a very cheap operation. -- PhilGoodwin
----
Phil, I think I see where you are going with this, but I think that the immutability of ValueObject''''''s is really part of their nature.  The old saw "is a date changed the same date or another date?" illustrates the issue.  Something like 12/4/98 is a pure value.  A variable can have that value, but the value itself can not be changed.  Imagine a class with a variable "numberOfWheels"  It may have the value 4 at times.  You can change the value of numberOfWheels, but you can not change the value of 4.  4 is a value.  To me, a ValueObject is something which represents a pure value. -- MichaelFeathers

But you can change the value of a variable that has been set to 4. You haven't changed the value of 4 but you have changed the value of the variable. The key issue is not whether the values themselves are immutable (we are agreed that they are) but whether the containers for those values should be immutable. What I am saying is that if you pass the values around by making copies of their representations into containers for those representations then the containers don't have to be immutable. If, on the other hand, you pass the values around by copying references to those containers then the containers do have to be immutable. The difference is that in the first case the containers ''hold''
the values and in the second the containers ''are'' the values. -- PhilGoodwin

It seems to me that you are confusing variables (l-values) and objects (r-values). It is true that a variable can be constant, but that is not what we are talking about when we speak of a ValueObject. There is nothing wrong with a variable holding one immutable ValueObject and then another. But in that case, it is the variable (container) which has changed, not the ValueObject. 
-- RussellGold

Actually, I think that the confusion is not at my end. It seems to me that people are confusing references to an object with the object itself. In Java all objects are held by reference so the difference can't really be exploited. In C++, however, you can hold an object by value. In that case the variable ''is'' the object. I think that the confusion might be between variables (l-values), values (r-values) and objects (either). A variable can either be an object-by-value or a reference to an object. ValueSemantics for objects-by-value are preserved by copying values between objects. ValueSemantics for objects-by-reference are preserved by using a CopyOnWrite mechanism. I had always thought that the story ended there. Are ValueObject''''''s simply objects that preserve ValueSemantics or is there something more to them? -- PhilGoodwin

Actually, in Java you can emulate C++'s constant values ''and'' constant references. The former, as already discussed, is done using immutable objects. The latter is achieved using ''final'' (object reference) variables. You can use both in combination to emulate something akin to C++ ''typedef''s in Java (though in a somewhat kludgy way) -- PeterSwords

----

''ValueObject''''''s, logically, should be immutable.  If we assume that, the following can be stated:''

* ''Whether we pass a ValueObject by reference or value is an implementation detail--we should be able to freely copy a ValueObject if it is more convenient.''
* ''If a particular copy of a ValueObject only has one referent, and that referent is then bound to a different ValueObject, a legimitate optimization is to update the ValueObject in place rather than creating a new object, updating the pointer, and destroying/garbage-collecting the old one.''
* ''CopyOnWrite semantics might be useful.''