Immutable Objects

Immutable objects are a great concept, an object that can not be altered after it was created. It is easy to debug and understand and it gives a lot of certainty just because it will never change. It is clear that we should aim to make objects immutable as much as possible but this sounds a lot easier than it actually is. Moreover the usability of immutable objects can pose a lot of problems as well.

How hard can it be to make an immutable object? This depends on what fields an object has. If it only contains primitive types this is very easy as defining them as constant is enough. As soon as you start working with more complex fields, such as references to other objects, lists or even a simple array this is a lot harder. Simply defining these fields as constants will only prevent changing the pointer to the objects from changing but the actual state of the object can still change.

If you have a reference to an object and it itself is immutable, then everything is still fine. You can accept it as an argument in the constructor and you can expose it without any danger of changing the state. If the object however is mutable you have to be careful. You can not simply use the object if it is passed in with the constructor as the caller still has a reference to the object and can change it behind your back. Changing this object would cause your immutable object to be changed and break its immutability. Whenever an object like this is passed in, you have to make a defensive copy of this. Whether a shallow or deep copy is required depends on the fields of the object and whether the object itself has references to other objects that might be shared with others. Exposing such an object is also only possible by returning a copy of the object as returning the actual object gives the caller the opportunity to change the state of the object.

It is clear that in simple cases and for simple objects, creating an immutable object is very straightforward. Once you are working with more complicated objects that contain references to other objects this already becomes a lot harder. But the true challenge with immutable objects is the usability of them. Most object will have some form of state that can change over time, using immutable objects for this is counter intuitive. You can still use immutable objects by creating a new object every time the actual state changes, but this object has to be created and held by some other object that can’t be immutable. Doing this too extreme will result in violating good Object Oriented design as the immutable objects become data objects and are swapped by some controller. It is the responsible of the controller to guard the values set for the immutable object, which does not always fit very well.

The biggest problem is that an immutable object reflects an immutable state, but in practice this is almost never the case. This forces you to split the object into small parts that can be made immutable and replaced if they ever change. An example of this would be a Coordinate consisting of (x,y), instead of changing the coordinate directly when the object has moved, you can just create a new coordinate for the new location. Note that this is only applicable to very small classes as it is stupid for higher level classes as the example below shows.

public class Coordinate {
private double x;
private double y;

public class Car {
private final Coordinate location;
private final double fuelLevel;
private final double travelledDistance;

Both Coordinate and Car are immutable object, but it is clear that the state of the car object will change often and creating a new object for this feels weird as we don’t have a new car every time.

The biggest problem in the example above is that the developer hangs on to the concept of immutable objects, even when it doesn’t fit the design. This developer might have been a big fan of immutable objects, or he might have heard that immutable objects are great and the solve all of your problems. It is however important to always remember in what situations something is good instead of just blindly taking over a design style.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s