Class with members that are mutable during creation but immutable afterwards

Question

I have an algorithm which creates a collection of objects. These objects are mutable during creation, since they start out with very little, but then they are populated with data in different places within the algorithm.

After the algorithm is completed, the objects should never be changed - however they are consumed by other parts of the software.

In these scenarios, is it considered good practice to have two versions of the class, as described below?

• The mutable one is created by the algorithm, then
• On completion of the algorithm, the data is copied into immutable objects which are returned.

Answer 1

You can perhaps use the builder pattern. It uses a separate 'builder' object with the purpose of collecting the necessary data, and when all data is collected it creates the actual object. The created object can be immutable.

Answer 2

A simple way to achieve this would be to have an interface that allows one to read properties and call only read only methods and a class that implements that interface which also lets you write that class.

Your method that creates it, deals with the former, and then returns the latter providing only a read only interface to interact with. This would require no copying and it allows you to easily fine-tune behaviors you want available to the caller as opposed to the creator.

Take this example:

public interface IPerson 
{
    public String FirstName 
    {
        get;
    }

    public String LastName 
    {
        get;
    }
} 

public class PersonImpl : IPerson 
{
    private String firstName, lastName;

    public String FirstName 
    {
        get { return firstName; }
        set { firstName = value; }
    }

    public String LastName 
    {
        get { return lastName; }
        set { lastName = value; }
    }
}

class Factory 
{
    public IPerson MakePerson() 
    {
        PersonImpl person = new PersonImpl();
        person.FirstName = 'Joe';
        person.LastName = 'Schmoe';
        return person;
    }
}

The only disadvantage to this approach is that one could simply cast it to the implementing class. If it were a matter of security, then simply using this approach is insufficient. A workaround for this is that you can create a facade class to wrap the mutable class, which simply presents an interface that the caller works with and cannot have access to the internal object.

In this way, not even casting will help you. Both can derive from the same read only interface, but casting the returned object will only give you the Facade class, which is immutable as it doesn't change the underlying state of the wrapped mutable class.

It's worth mentioning that this doesn't follow the typical trend in which an immutable object is constructed once and for all through its constructor. Understandably, you might be having to deal with many parameters, but you should ask yourself if all these parameters need to be defined up front or if some can be introduced later. In that case, a simple constructor with only required parameters should be used. In other words, don't use this pattern if it is covering up another problem in your program.

Answer 3

You can use the Builder pattern as @JacquesB says, or alternatively think why is it actually that these objects of yours have to be mutable during creation?

In others words, why does the process of creating them have to be spread in time, as opposed to passing all the required values into the constructor and creating instances in one go?

Because the Builder could be a good solution for the wrong problem.

If the issue is that you end up with a constructor that's like 10 parameters long, and you'd like to mitigate it by building the object little by little, it could indicate that the design is messed up, and these 10 values should be "bagged" / grouped into a few objects... or the main object split into a few smaller ones...

In which case - stick to immutability all the way, just improve the design.