ValueObject

See some details on the SimpleTypesGenerator page.

Dealing with mutable fields in the ValueObject

If the ValueObject holds mutable objects in fields there need to be taken care that the modified state is propagated (or not) through the system. There are several approaches possible and supported by the ValueObject generator. These are explained here in detail.

Ignore mutability of Objects stored in fields

This might be either because the propagation of modifications in mutable field objects is intended or there was a active decision that the caller must take care for the copying whenever needed. This might be to reduce the amount of objects being created. Both cases should be '''documented''' with the field to make users of the class aware of this fact.

<valueObject ...>
  ...
  <member 
    name="modification date"
    type="java.util.Date">
    <decription>
      The modification date. Field is not copied, callers must 
      copy the returned object before modifying it.
    </description>
  </member>
</valueObject>

Store value in a static final field

A other way that on the one hand ignores the fact that the stored Object is mutable but makes this more explicit is to make the field final so that the field as such can not be modified, but only the content of the field.

No setters will be generated for this field, but the value van nevertheless be modified by modifying the content of the field. For example foo.getDate().setTime(0);. This pattern is very common when dealing with members of the collection classes.

<valueObject ...>
  ...
  <member 
    name="member list" type="java.util.List"
    final="true" initial-value="new java.util.ArrayList()">
    <decription>
      List of assigned members. All added elements must be of type Member. 
      To add a new member call getMemberList().add(...)
    </description>
  </member>
</valueObject>

Store and return a copy of the field created by clone

To avoid the state being shared, the field could be cloned whenever it is accesses.

With build 717 the member element of ValueObjects supports an additional attribute called copyValue if this attribute is set to the value clone the object is always copied using clone whenever its value is set or retrieved.

<valueObject ...>
  ...
  <member 
    name="modification date" type="java.util.Date"
    copyValue="clone">
    <decription>Date of the last modification</description>
  </member>
</valueObject>

The value stored as modification date is always cloned before being stored or retrieved. This makes it impossible that the state is (accidentally) shared between instances. It is the creator of the value objects responsibility to ensure that the used type supports the clone method. Otherwise the code will most likely not even compile.

Store and return a copy of the field created by a copy constructor

With build 717 the member element of ValueObjects supports an additional attribute called copyValue if this attribute is set to the value constructor the object is always copied using a copy constructor whenever its value is set or retrieved.

<valueObject ...>
  ...
  <member 
    name="selected point" type="java.awt.Point"
    copyValue="constructor">
    <decription>The most important point on the plane</description>
  </member>
</valueObject>

The value stored as selected point is always copied using the copy constructor of Point before being stored or retrieved. This makes it impossible that the state is (accidentally) shared between instances. It is the creator of the value objects responsibility to ensure that the used type supports a copy constructor. Otherwise the code will most likely not even compile.