At what point do immutable classes become a burden?

Question

When designing classes to hold your data model I've read it can be useful to create immutable objects but at what point does the burden of constructor parameter lists and deep copies become too much and you have to abandon the immutable restriction?

For example, here is an immutable class to represent a named thing (I'm using C# syntax but the principle applies to all OO languages)

class NamedThing
{
    private string _name;    
    public NamedThing(string name)
    {
        _name = name;
    }    
    public NamedThing(NamedThing other)
    {
         this._name = other._name;
    }
    public string Name
    {
        get { return _name; }
    }
}

Named things can be constructed, queried and copied to new named things but the name cannot be changed.

This is all good but what happens when I want to add another attribute? I have to add a parameter to the constructor and update the copy constructor; which isn't too much work but the problems start, as far as I can see, when I want to make a complex object immutable.

If the class contains may attributes and collections, containing other complex classes, it seems to me the constructor parameter list would become a nightmare.

So at what point does a class become too complex to be immutable?

Answer 1

When they become a burden? Very quickly (specially if your language of choice does not provide sufficient syntactic support for immutability.)

Immutability is being sold as the silver bullet for the multi-core dilemma and all that. But immutability in most OO languages forces you to add artificial artifacts and practices in your model and process. For each complex immutable class you must have an equally complex (at least internally) builder. No matter how you design it, it stills introduces strong coupling (thus we better have a good reason to introduce them.)

It is not necessarily possible to model everything in small non-complex classes. So for large classes and structures, we artificially partition them - not because that makes sense in our domain model, but because we have to deal with their complex instantiation and builders in code.

It is worse still when people take the idea of immutability too far in a general purpose language like Java or C#, making everything immutable. Then, as a result, you see people forcing s-expression constructs in languages that do not support such things with ease.

Engineering is the act of modeling through compromises and trade-offs. Making everything immutable by edict because someone read that everything is immutable in X or Y functional language (a completely different programming model), that is not acceptable. That is not good engineering.

Small, possibly unitary things can be made immutable. More complex things can be made immutable when it makes sense. But immutability is not a silver bullet. The ability to reduce bugs, to increase scalability and performance, those are not the sole function of immutability. It is a function of proper engineering practices. After all, people have written good, scalable software without immutability.

Immutability gets to become a burden really fast (it adds to accidental complexity) if it is done without a reason, when it is done outside of what it make sense in the context of a domain model.

I, for one, try to avoid it (unless I'm working in a programming language with good syntactic support for it.)

Answer 2

I went through a phase of insisting on classes being immutable where possible. Had builders for pretty much everything, immutable arrays, etc, etc. I found the answer to your question is simple: At what point do immutable classes become a burden? Very quickly. As soon as you want to serialize something, you have to be able to deserialize, which means it must be mutable; as soon as you want to use an ORM, most of them insist on properties being mutable. And so on.

I eventually replaced that policy with immutable interfaces to mutable objects.

class NamedThing : INamedThing
{
    private string _name;    
    public NamedThing(string name)
    {
        _name = name;
    }    

    public NamedThing(NamedThing other)
    {
        this._name = other._name;
    }

    public string Name
    {
        get { return _name; }
        set { _name = value; }
    }
}

interface INamedThing
{
    string Name { get; }
}

Now the object has flexibility but you can still tell calling code that it shouldn't edit these properties.

Answer 3

I don't think there is a general answer to this. The more complex a class is, the harder it is to reason about its state changes, and the costlier it is to create new copies of it. So above some (personal) level of complexity it will become too painful to make/keep a class immutable.

Note that a too complex class, or a long method parameter list are design smells per se, regardless of immutability.

So usually the preferred solution would be to break such a class into multiple distinct classes, each of which can be made mutable or immutable on its own. If this is not feasible, it can be turned mutable.

Answer 4

You can avoid the copy problem if you store all of your immutable fields in an inner struct. This is basically a variation of the memento pattern. Then when you want to make a copy, just copy the memento:

class MyClass
{
    struct Memento
    {
        public int field1;
        public string field2;
    }

    private readonly Memento memento;

    public MyClass(int field1, string field2)
    {
        this.memento = new Memento()
            {
                field1 = field1,
                field2 = field2
            };
    }

    private MyClass(Memento memento) // for copying
    {
        this.memento = memento;
    }

    public int Field1 { get { return this.memento.field1; } }
    public string Field2 { get { return this.memento.field2; } }

    public MyClass WithNewField1(int newField1)
    {
        Memento newMemento = this.memento;
        newMemento.field1 = newField1;
        return new MyClass(newMemento);
    }
}

Answer 5

You have a couple of things at work here. Immutable data sets are great for multithreaded scalability. Essentially, you can optimize your memory quite a bit so that one set of parameters is one instance of the class--everywhere. Because the objects never change you don't have to worry about synchronizing around accessing its members. That's a good thing. However, as you point out, the more complex the object is the more you need some mutability. I would start with reasoning along these lines:

• Is there any business reason why an object can change its state? For example, a user object stored in a database is unique based on its ID, but it has to be able to change state over time. On the other hand when you change coordinates on a grid, it ceases to be the original coordinate and so it makes sense to make coordinates immutable. Same with strings.
• Can some of the attributes be computed? In short, if the other values in the new copy of an object are a function of some core value you pass in, you can either compute them in the constructor or on demand. This reduces the amount of maintenance as you can initialize those values the same way on copy or create.
• How many values make up the new immutable object? At some point the complexity of creating an object becomes non-trivial and at that point having more instances of the object can become a problem. Examples include immutable tree structures, objects with more than three passed in parameters, etc. The more parameters the more possibility of messing up the order of parameters or nulling out the wrong one.

In languages that only support immutable objects (such as Erlang), if there is any operation that seems to modify the state of an immutable object, the end result is a new copy of the object with the updated value. For example, when you add an item to a vector/list:

myList = lists:append([[1,2,3], [4,5,6]])
% myList is now [1,2,3,4,5,6]

That can be a sane way of working with more complicated objects. As you add a tree node for example, the result is a new tree with the added node. The method in the above example returns a new list. In the example in this paragraph the tree.add(newNode) would return a new tree with the added node. For the users, it becomes easy to work with. For the library writers it becomes tedious when the language doesn't support implicit copying. That threshold is up to your own patience. For the users of your library, the most sane limit I've found is about three to four parameters tops.

Answer 6

If you have multiple final class members and don't want them to be exposed to all objects who need to create it, you can use the builder pattern:

class NamedThing
{
    private string _name;    
    private string _value;
    private NamedThing(string name, string value)
    {
        _name = name;
        _value = value;
    }    
    public NamedThing(NamedThing other)
    {
        this._name = other._name;
        this._value = other._value;
    }
    public string Name
    {
        get { return _name; }
    }

    public static class Builder {
        string _name;
        string _value;

        public void setValue(string value) {
            _value = value;
        }
        public void setName(string name) {
            _name = name;
        }
        public NamedThing newObject() {
            return new NamedThing(_name, _value);
        }
    }
}

the advantage is that you can easily create a new object with only a different value of a differtent name.

Answer 7

So at what point does a class become too complex to be immutable?

In my opinion it's not worth bothering to make small classes immutable in languages like the one you are showing. I'm using small here and not complex, because even if you add ten fields to that class and it does really fancy operations on them, I doubt it's going to take kilobytes let alone megabytes let alone gigabytes, so any function using instances of your class can simply make a cheap copy of the whole object to avoid modifying the original if it wants to avoid causing external side effects.

Persistent Data Structures

Where I find personal use for immutability is for big, central data structures that aggregate a bunch of teeny data like instances of the class you're showing, like one that stores a million NamedThings. By belonging to a persistent data structure which is immutable and being behind an interface that only allows read-only access, the elements that belong to the container become immutable without the element class (NamedThing) having to deal with it.

Cheap Copies

The persistent data structure allows regions of it to be transformed and made unique, avoiding modifications to the original without having to copy the data structure in its entirety. That's the real beauty of it. If you wanted to naively write functions that avoid side effects that input a data structure that takes gigabytes of memory and only modifies a megabyte's worth of memory, then you'd have to copy the entire freaking thing to avoid touching the input and return a new output. It's either copy gigabytes to avoid side effects or cause side effects in that scenario, making you have to choose between two unpleasant choices.

With a persistent data structure, it allows you to write such a function and avoid making a copy of the entire data structure, only requiring about a megabyte of extra memory for the output if your function only transformed a megabyte's worth of memory.

Burden

As for the burden, there's an immediate one at least in my case. I need those builders people are talking about or "transients" as I call them to be able to effectively express transformations to that massive data structure without touching it. Code like this:

void transform_stuff(MutList<Stuff>& stuff, int first, int last)
{
     // Transform stuff in the range, [first, last).
     for (; first != last; ++first)
          transform(stuff[first]);
}

... then has to be written like this:

ImmList<Stuff> transform_stuff(ImmList<Stuff> stuff, int first, int last)
{
     // Grab a "transient" (builder) list we can modify:
     TransientList<Stuff> transient(stuff);

     // Transform stuff in the range, [first, last)
     // for the transient list.
     for (; first != last; ++first)
          transform(transient[first]);

     // Commit the modifications to get and return a new
     // immutable list.
     return stuff.commit(transient);
}

But in exchange for those two extra lines of code, the function is now safe to call across threads with the same original list, it causes no side effects, etc. It also makes it really easy to make this operation an undoable user action since the undo can just store a cheap shallow copy of the old list.

Exception-Safety or Error Recovery

Not everyone might benefit as much as I did from persistent data structures in contexts like these (I found so much use for them in undo systems and non-destructive editing which are central concepts in my VFX domain), but one thing applicable to just about everyone to consider is exception-safety or error recovery.

If you want to make the original mutating function exception-safe, then it needs rollback logic, for which the simplest implementation requires copying the entire list:

void transform_stuff(MutList<Stuff>& stuff, int first, int last)
{
    // Make a copy of the whole massive gigabyte-sized list 
    // in case we encounter an exception and need to rollback
    // changes.
    MutList<Stuff> old_stuff = stuff;

    try
    {
         // Transform stuff in the range, [first, last).
         for (; first != last; ++first)
             transform(stuff[first]);
    }
    catch (...)
    {
         // If the operation failed and ran into an exception,
         // swap the original list with the one we modified
         // to "undo" our changes.
         stuff.swap(old_stuff);
         throw;
    }
}

At this point the exception-safe mutable version is even more computationally expensive and arguably even harder to write correctly than the immutable version using a "builder". And a lot of C++ developers just neglect exception-safety and maybe that's fine for their domain, but in my case I like to make sure my code functions correctly even in the event of an exception (even writing tests that deliberately throw exceptions to test exception safety), and that makes it so I have to be able to rollback any side effects a function causes halfway into the function if anything throws.

When you want to be exception-safe and recover from errors gracefully without your application crashing and burning, then you have to revert/undo any side effects a function can cause in the event of an error/exception. And there the builder can actually save more programmer time than it costs along with computational time because: ...

You don't have to worry about rolling back side effects in a function which doesn't cause any!

So back to the fundamental question:

At what point do immutable classes become a burden?

They're always a burden in languages that revolve more around mutability than immutability, which is why I think you should use them where the benefits significantly outweigh the costs. But at a broad enough level for big enough data structures, I do believe there are many cases where it's a worthy trade-off.

Also in mine, I only have a few immutable data types, and they're all huge data structures intended to store massive numbers of elements (pixels of an image/texture, entities and components of an ECS, and vertices/edges/polygons of a mesh).