Reading this post makes me think of a rather underappreciated (and apparently contentious?) class: String. String’s immutability makes life in Java unbelievably easier. If String were mutable, it is no longer an implicitly safe key-value for hashing; you would have to enforce the de facto immutability through encapsulation. On the other hand, since it is mutable, you can use it freely.

Whenever String is modified, a new String is created that represents the requested State. The original remains the same, and the newly created string is not inflexible when it comes to apparent modification.

You could use this idea as an alternative to the above pattern. Whenever you want to change the state of the object, you clone the object, passing in the new state.

Of course, this has some dangers: String concatenation is very expensive as a consequence of this, since new String’s must be created at every step. Of course, StringBuilder affords a truly mutable String that one could use, while still implementing the CharSequence interface that String does.

Because of the complementary nature of these two classes, the developer can intelligently, and easily, scale forward and backward the flexibility he wishes to present to the end-user. Furthermore, he can guarantee thread-safety (Which I think was mentioned in the comments) along with immutability of the parent (assuming this object has owners).

Something that I also appreciate, is that if you have immutable state, you can guarantee validity at all times: You’re always guaranteed an object that has proper state. This is different from mutable objects, which have to go to alot more trouble to ensure their state.

As an example, imagine setting two points on a line. After you set the first point, but before you set the second, the object is in an invalid state. The state is valid to the Line class itself, but clients of that class would not be able to sensibly work with this value. This is the true essence of thread-safety, and I think it stems from solid, proactive design.

The Date class (And, ironically, the Point class) are two examples that I (and many others) think should have been immutable, but weren’t. I imagine both were made mutable in the interests of performance and simplicity, but I think more damage was done in the long-run. This is especially true considering they could have followed the Foo/FooBuilder pattern, or the pattern discussed in the post above, instead.

All in all, favor immutability. :)

public APIReadOnlyPoint asReadOnly(APIReadWritePoint point) {
return(point);
}

So this raise the question of the meaning of immutable objects.
Immutable objects are under no condition modifiable. Best examples are the object representations of primitives (Integer, Boolean, etc.) and String.
JDK 1.3 could gain a huge performance gain by caching all strings and string creation and comparision was almost done in no time.

It is really nice to see what is possible with generics as Stephan demonstrated, but for this case it would rather be advisable to keep things simple and just have two different classes: One mutable and one immutable if really needed.

public interface Point
{
int getX(); int getY();
}

public class ImmutablePoint implements Point
{
private int x;
private int y;
public int getX(){return x;}
public int getY(){return y;}

public ImmutablePoint(int x1, int y1)
{
x=x1;y=y1;
}

public MutablePoint mutablePoint()
{
return new MutablePoint(x,x);
}
}

public class MutablePoint implements Point
{
protected int x;
protected int y;

public int getX(){return x;}
public int getY(){return y;}

public void setX(int x1){x=x1;}
public void setY(int y1){y=y1;}

public MutablePoint(int x1, int y1)
{
x=x1;y=y1;
}

public ImmutablePoint immutablePoint()
{
// we could here also lookup in a cache for a immutable object representing the Point and return only this instance.
return new ImmutablePoint(x,y);
}
}

public APIReadOnlyPoint getPoint();

The users of that method know that they’re getting a point that they cannot call the setters on, and the compiler won’t let them. No chance of exceptions being thrown.

public interface APIReadOnlyPoint {
public T getX();

public T getY();
}

public interface APIReadWritePoint extends APIReadOnlyPoint {
public void setX(T x);

public void setY(T y);
}

public class ReadOnlyPoint implements APIReadOnlyPoint {
protected T x;
protected T y;

public ReadOnlyPoint(final T x, final T y) {
this.x = x;
this.y = y;
}

@Override
public T getX() {
return x;
}

@Override
public T getY() {
return y;
}
}

public final class ReadWritePoint extends ReadOnlyPoint implements
APIReadWritePoint {
public ReadWritePoint(final T x, final T y) {
super(x, y);
}

public ReadWritePoint(final ReadOnlyPoint point) {
super(point.getX(), point.getY());
}

@Override
public void setX(final T x) {
this.x = x;
}

@Override
public void setY(final T y) {
this.y = y;
}
}

The big advantage of immutable Objects is that they are immutable and their state will not change. Otherwise you have to take care about synchronization and the java memory model.
So your suggestion will break the immutable contract.

I would have expected to get a new mutable object by changing to mutable. By the I would also expect to be able to have the possibility to get a immutable version from the mutable object.

So the makeMutable method needs a modification:
# public MutablePoint makeMutable() {
# return new DefaultPoint(x,y);
# }

Anyway, the DefaultPoint ist not really an immutable object, so it is not the best practice to use this kind of code and rely on the immutablity of the point.

With Qi4j I also would model the mutable state as a different concern.

http://www.jroller.com/rickard/entry/qi4j_status_report

point() is a factory (Fluent Interface style), see the method in DefaultPoint:


public Point point(int x, int y) {
return new DefaultPoint(x,y);
}


For more code this could be packaged into a new Object PointFactory oder PointBuilder.

Just my 2 cents: I think that there’s a little bug. Instead of:

Point point = point(10,10);

it should be:

Point point = new DefaultPoint(10,10);

isn’t it?