Immutability Through Interfaces
It is often desirable to have immutable objects, objects that cannot be modified once constructed. Typically, an immutable object has fields that are declared as final and are set in the object constructor. There are getters for the fields, but no setters since the values cannot be saved. Once created, the object state doesn’t change and the objects can be shared across different threads since the state is fixed. There are plenty of caveats to that statement, for example if you have a list, while the list field reference may be final, the list itself may be able to change and have values added and removed which would spoil the immutability.
Achieving this state can often be difficult because we rely on a number of tools and frameworks that may not support immutability such as any framework that builds an object by creating it and then setting values on it.
However, one way around this would be to take a mutable object and make it immutable through interfaces. We do this by creating an interface that represents all the getters for an object, but none of the setters.
Given a domain entity of a person with an id, first and last name fields we can define an immutable interface :
public interface ImmutablePerson { public int getId(); public String getFirstName(); public String getLastName(); }
We can then implement this interface in our person class :
public class PersonEntity implements ImmutablePerson { private int id; private String firstName; private String lastName; public int getId() { return id; } public void setId(int id) { this.id = id; } public String getFirstName() { return firstName; } public void setFirstName(String firstName) { this.firstName = firstName; } }
Our API deals with the PersonEntity
class internally, but exposes the object as the ImmutablePerson
only.
public ImmutablePerson loadPerson(int id) { PersonEntity result = someLoadingMechanism.getPerson(id); result.setxxxxx(somevalue); //we can change it internally return result; //once it has been returned it is only accessed as an immutable person }
To return a mutable instance for modification, you can return the PersonEntity
. Alternatively, you can add a MutablePerson
interface with just the setters and implement that. Unless you want to keep casting between the Immutable/Mutable types, the MutablePerson
interface can extend the ImmutablePerson
interface so the writable version is also readable.
public interface MutablePerson extends ImmutablePerson { public void setId(int id) { public void setFirstName(String firstName); public void setLastName(String lastName); }
Granted, someone can easily cast the object to a PersonEntity
or MutablePerson
and change the values, but then, you can also change static final variables with reflection if you wanted to. The ability to cast the object to make it writable only could be an internal-use only feature.
This mechanism can be used to return immutable objects from persistence layers. There are some caveats with certain ORM tools since they use lazy loading mechanisms that would break the immutability. Underneath the interface it is still a mutable object. With some additional code, you could create immutable collections by wrapping the underlying collections in read only collections and returning them to the user.
Some of the JVM benefits of immutability granted upon variables marked as final would not be given to this type of solution since the underlying variables are not final or immutable.
2 thoughts on “Immutability Through Interfaces”
Comments are closed.
I think you mistakenly understand immutability.
Immutability is not about protecting the outside from mutating your object. This is merely a consequence.
Immutability is about thread-safety, cheap copy on write, …
For example, immutable sequences in functionnal programming or strings in java are immutable.
l = [1]
l = l + [2]
l = l + [3]
In memory, you may really have pointers on the lists (compare this to the traditional implementation where you must copy the whole collection to keep it thread safe) !
What you have done here with ImmutablePerson is the same as Java ImmutableList which is only a VIEW of the list (hence, if I change the underlying structure then the view also changes and so is not immutable).
See ImmutableList of guava for a real immutable list using the technique I described.
Immutability is not about thread safety. The definition of immutability is an object that cannot be changed. Thread safety is just one of the benefits of that.
Yes, the ImmutablePerson is a read only view of the object, but since even class members declared as final can be changed through reflection, we only ever have immutable views of mutable objects.
It was assumed that once the ImmutablePerson had been sent to the client, it would not be changed by the API internally. The goal was to make mutable objects immutable by some mechanism other than having to copy the whole thing to a duplicate immutable class.
I only lightly mentioned collections because the options for implementing them immutably or thread safely vary greatly depending on the underlying object and how the collections on the final object will be used.