So, mutability is evil. At least some people think so - including myself. Because of that, I have been thinking about immutable business objects for some time now, and here are some of my ideas. I don’t really know yet if these are good ideas and I have not yet tried to implement this. Maybe you could help me out here: Please send me your comments and suggestions, you can find my contact details at the bottom of this page.

I know that the code style of the examples below does not conform to the Java Bean conventions. This also means that code like this would not work properly with lots of existing frameworks. For example, you could not use these business objects together with Hibernate or JPA. Also, the names of certain concepts in the code below could probably be improved. Anyway, I think this is a nice thought experiment, so please continue with me.

What I want is a framework that allows me to easily write immutable business objects. Ideally I only want to write an interface, the framework would create the implementation for me. (N.B.: This should be really easy to implement with dynamic proxies.)

public interface Person {
    public FirstName firstName();
    public LastName lastName();

    public Address address();
}

public interface Address {
    public Street street();
    public StreetNumber streetNumber();
}

We need a way to create new objects and set the values. We could do this using a static method that does the heavy lifting:

Person person = create(Person.class, new Values<Person>() {
    public void setValues(Person p) {
        set(p.firstName()).to(new FirstName("Davdi")); //Typo, name has to be changed later!
        set(p.lastName()).to(new LastName("Tanzer"));

        set(p.address()).to(create(Address.class, new Values<Address>() {
            public void setValues(Address a) {
                set(a.street()).to(new Street("Brunnenfeldstr."));
                set(a.streetNumber()).to(new StreetNumber("5a"));
            }
        }));
    }
});

The “Values” class would probably be quite hard to get right, but I think it would be worth it. Why? See below…

We also need a way to create a new immutable object based on an existing one. In this example, we want to change the first name of our peron object because there was a typo in our database. Another static “create” method could do this job:

Person newP = create(person, new Values<Person>() {
    public void setValues(Person p) {
        set(p.firstName()).to(new FirstName("David"));
        set(p.address()).to(create(person.address(), new Values<Address>() {
            public void setValues(Address a) {
                set(a.streetNumber()).to(new StreetNumber("6a"));
            }
        }));
    }
});

The nice thing here is not only that all values are immutable. We also have defined state changes: There is no point in time where we have access to a person object where the name was already changed but the address is still wrong (*). What I have outlined here is really more of a struct than an object in the OO sense. But I really think it would be nice to have something like this. I just don’t see a way how we could implement something like this that would still play nicely with a framework like JPA :(

(*) If “create” and “Values<T>” are implemented correctly.