Comments on my Java pattern for Mutable turned Immutable objects

If you really want to avoid object creation, you have no other choice as dropping final, e.g.:

public interface Something {

    public int getSomeInteger();
    public String getSomeString();

    public static class Mutable implements Something {
        private int someInteger;
        private String someString;
        private boolean open = true;

        public int getSomeInteger() {
            return someInteger;
        }

        public String getSomeString() {
            return someString;
        }

        public Something.Mutable setSomeInteger(int someInteger) {
            assert open;
            this.someInteger = someInteger;
            return this;
        }

        public Something.Mutable setSomeString(String someString) {
            assert open;
            this.someString = someString;
            return this;
        }

        public Something make() {
            open = false;
            return this;
        }
    }
}

But this pattern is brittle, and the Java runtime is pretty good in dealing with object creation these days, so if you don't write a graphic or math lib or so, you shouldn't care about.

Effective Java 2nd Edition has a complete chapter on this topic: Item 2: Consider a builder when faced with many constructor parameters.

You can put a freezed flag into the class then set it in the build method and check it in every setter.

public class Something {
    private int someInteger;
    private String someString;

    private boolean freezed;

    public Something() {
    }

    public int getSomeInteger() {
        return someInteger;
    }

    public Something setSomeInteger(final int someInteger) {
        checkFreezed();
        this.someInteger = someInteger;
        return this;
    }

    public String getSomeString() {
        return someString;
    }

    public Something setSomeString(final String someString) {
        checkFreezed();
        this.someString = someString;
        return this;
    }

    private void checkFreezed() {
        if (freezed) {
            throw new IllegalStateException();
        }
    }

    public Something build() {
        freezed = true;
        return this;
    }
}

Of course it has its own drawbacks:

[...] it can cause errors at runtime, as the compiler cannot ensure that the programmer calls the freeze method on an object before using it.

(From Effective Java 2nd Edition, Item 2: Consider a builder when faced with many constructor parameters)

You can avoid some repetition with an IDE plugin which generates the builder for you (for example, with fluent-builders-generator-eclipse-plugin).

Note that the term finalize is used for a completely different mechanism in Java. I'd use the regular build word.

Edit: Anyway, it's possible with only one object creation via reflection but it's really ugly. I don't think that it's worth it, object creation is cheap nowadays.

Something:

public interface Something {

    int getSomeInteger();

}

SomethingReflected:

import java.lang.reflect.Field;

public class SomethingReflected implements Something {

    private final int someInteger;

    public SomethingReflected() {
        this.someInteger = 0;
    }

    public SomethingReflected(final int someInteger) {
        super();
        this.someInteger = someInteger;
    }

    public SomethingReflected setSomeInteger(final int someInteger) {
        updateField("someInteger", someInteger);
        return this;
    }

    private void updateField(final String fieldName, final int value) {
        try {
            final Field field = this.getClass().getDeclaredField(fieldName);
            field.setAccessible(true);
            field.set(this, value);
        } catch (final NoSuchFieldException e) {
            throw new AssertionError(e);
        } catch (final IllegalAccessException e) {
            throw new AssertionError(e);
        }
    }

    @Override
    public int getSomeInteger() {
        return someInteger;
    }

    public Something build() {
        return this;
    }
}

Another drawback is that clients could misuse it easily:

final SomethingReflected somethingReflected = new SomethingReflected();
somethingReflected.setSomeInteger(5);

final Something something = somethingReflected.build();

assertEquals(5, something.getSomeInteger());

somethingReflected.setSomeInteger(6);
final Something something2 = somethingReflected.build();

assertEquals(5, something.getSomeInteger()); // fails, returns 6