How and when to apply immutability pattern

Immutability, it is very important concept to development of complex applications and there are creational design patterns to support immutability pattern, but should we implement this pattern without understanding it??? This is the big question.

So first lets understand the immutability pattern, I am sure you are aware of what an immutable class is but this pattern is when you create all your objects immutable. You give only one method to change the object in each class and that is constructor. Once you constructed the object, nothing can change it. This of-course makes objects the good candidate for multi-threading and hash based collection usage. However, this becomes the overhead sometimes. Lets see what are the ways to modify state of an immutable object.

Lets consider you have such a class with seven fields and five of them can change, you can change the state with these options

1. Use a builder pattern
2. Provide additional multiple constructors that takes original object of same type and one parameter with new value of a field
3. Use constructor with all seven fields all the times

First we need to understand and revise what is a variable, a variable is something that can vary, whose value can change over time, but if a variable is of immutable type, isn't it defeating the whole concept of variable. I know you can create new object with changed values and reassign to variable but that is inconvenient sometimes like when you want to share states between two different areas of application or threads or when you have complex processing which modifies the object at number of places.

Now consider the overhead of each option (Note we are not talking about one or two such classes in project, we are talking about all your DTOs immutable)

1. Builder pattern will force you to create one builder per DTO, additional class/code to maintain means additional bugs also everywhere you use your builder, code is not clean.
2. Additional constructor means lot many constructors, as many fields that can change, again too much code.
3. Use one single constructor means code not clean but really a problem when there are many fields.

So lets see where is this a good option to implement this pattern.

1. When you create a framework that is shared and used in number of projects that are not in your control, this is a good candidate. This makes your framework robust and ensures clients will get what they configure.
2. In you application where you manage various configs, so that it is assured that your configs will not change by mistake.
3. In a simple CRUD application where there is no processing.

But this pattern is not at all good for any application that has a little bit of processing. Later in your project cycle when things go into maintenance, it will really become smelly code when you patch irrelevant logic in places where it does not belong just because you can not modify your object anywhere and everywhere.

Alternatively, you can can consider giving behavior to your objects to change states instead of just setters, this will really make your code concise, clean and more object oriented instead. So at the end, I would suggest you to think well before choosing this pattern, think of future maintenance and support.