Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Immutability Through Interfaces

DZone's Guide to

Immutability Through Interfaces

· Java Zone
Free Resource

What every Java engineer should know about microservices: Reactive Microservices Architecture.  Brought to you in partnership with Lightbend.

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 aMutablePerson 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.

Microservices for Java, explained. Revitalize your legacy systems (and your career) with Reactive Microservices Architecture, a free O'Reilly book. Brought to you in partnership with Lightbend.

Topics:

Published at DZone with permission of Andy Gibson, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

THE DZONE NEWSLETTER

Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

X

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}