## Java Recruitment Questions - Immutable Objects

04 Feb 2020  Michal Fabjanski  7 mins read.

# Java Recruitment Questions - Immutable Objects

In Java, object variability is something very common. Until recently, it was normal for most beans to have getters and setters (In many projects this trend is still continuing). Increasingly, at interviews, interviewers ask: “What are immutable objects and what are their advantages and disadvantages?”

# What is an immutable object?

An immutable object is one which, after being created and initialized, remains unchanged and, importantly, cannot be changed (in a conventional way, of course). This means that such an object does not provide methods that allow changing its state. And all its fields are private (or public final).

This changeability is a little apparent, because, using reflection, you can change the field values in each class. However, this does not mean that for this reason, we should give up immutable objects.

# How to ensure the object’s immutability?

Apart from the fact that all fields should be private, they should be final. And the class itself should be marked as final so that it cannot be inherited. Such an object should not provide methods to modify its internal state, e.g. setters.

But private, final fields are not everything. It is important what types of data we store in these fields. It should also be unchangeable! If the fields in your object are primitives, primitive wrappers or Strings then there is no problem. All these types are immutable. But if you use your own objects, you must ensure that they are unchangeable.

If you use a collection, you must also ensure that it remains immutable. There are several possibilities:

• You can use special methods from the Collections class that return an appropriate unmodified view of the collection:
• static <T> List<T> unmodifiableList(List<? extends T> list)
• static <T> Set<T> unmodifiableSet(Set<? extends T> s)
• static <K,V> Map<K,V> unmodifiableMap(Map<? extends K,? extends V> m) Each of these methods takes a list, a set or a map as an argument and returns the list, set or map with the same content as the argument, but different from the original in that the attempt to change them, for example add or remove, causes an exception UnsupportedOperationException
• Use the immutable collections. If you are using Java 8 or above, you must use a library that will provide you with an implementation of the unchanging collections (e.g. Guava). If you are using newer versions of Java (9+), you have a collection that is immutable in the standard packages, e.g. List.of("a", "b", "c");. In Java 10, there are also copyOf(...) methods that allow you to copy the standard collection and convert it to the fixed one.

If you use a primitive array - you have a little problem because the arrays are inherently changeable. And using them in immutable objects is pointless. Of course, when creating an object, we can copy all arrays, but this does not change the fact that the copied arrays are also changeable. In this case, it is best to use the collection.

# How to create immutable objects?

Such objects can be created in three ways. Through the constructor and that is the easiest way. But it has a fundamental disadvantage. The more fields to initiate, the more parameters in the constructor. That’s why you shouldn’t create objects that have more than 2-3 fields.

Another way is the factory method. As with the constructor, the more fields, the more parameters. But this approach has such an advantage that we can create several such methods with a different names, with different set of parameters, which improves readability.

A third way to create immutable objects is to use the builder pattern. In order to use the builder, it must be implemented inside the class so that it has access to private class fields.

We can write such a builder manually or use some kind of IDE plugin to generate it for us. Another option is to use Lombok and @Builder annotation.

These objects make us avoid accidental changes, often in very inappropriate places. If an object is changeable, there will definitely be someone who wants to change it where it should not.

A good example of such a situation is the object that we pass as a parameter of the method. Such an object can be passed between multiple application layers, between multiple method calls. It can be passed on very deep in the call hierarchy. This makes it very difficult to identify where it was changed. This can lead to many strange and difficult to solve problems.

Using immutable objects we do not have such problems and the design of our application improves.

Invariant objects are also safe for multithreaded use. If an object is not changed, it can be safely transferred between threads without synchronization.

Another advantage is that such objects are ideal as key objects in maps. In a situation where keys are variable, after changing the key object its hashcode changes, making it impossible to find the stored value in HashMap.