Immutability and Readability

Question

So I've been reading Effective Java by Joshua Bloch and noticed two points which I actually have encountered in my work.

Point 1: Making setter methods to make code more readable. In his example, we have a class with a ridiculously huge constructor. When people instantiate the class, it's hard to tell what's going on with all the parameters. Thus, he suggested making a minimalistic constructor and have setter methods for all other options, so instead of...

MyClass clazz = new MyClass(a, b, c, d, e, f, g);

you would write....

MyClass clazz = new MyClass(a, b, c);
clazz.setDitto(d);
clazz.setEcho(e);
clazz.setFunzies(f);
clazz.setGumballs(g);

Which, as a huge supporter of readable code, I liked a lot.

Point 2: In general, he suggested having immutable classes. He goes into great depth on why having immutable classes is much better than having a class that could be in several different states. I can definitely say that he sold the idea to me, and I can't wait to make most classes I write from now on immutable, except....

What happens when you have an immutable class with a huge constructor? You can't make setter methods for it; that would break immutability. I tried skimming through the rest of the book, but I don't think he covers a solution for this.

There is the possibility of making one-time use setter methods, but just the fact that a setter method is available to a class that is supposedly immutability is disheartening, even if it does just throw an Exception if you try it subsequent times.

Does anyone have any good ideas on how to handle this problem? I'm currently facing this issue at work where I have an Immutable class with a huge constructor which I'd like to refactor to something that's more readable without breaking immutability.

Answer 1

One option is to provide a separate builder class that provides the setters, which is responsible for constructing the actual object.

In the second edition of Bloch's "Effective Java", item 2 illustrates this for an immutable class. The key ideas are:

• The builder has a mutable field for each option.
• The builder passes itself as a single argument to the immutable class's constructor.

Answer 2

Introduce Parameter Object , maybe? It kind of moves the problem around, but maybe in useful ways. Your parameter object needs no methods; it just holds the data, and you set it up, instead of your real class. Then your real class initializes itself in the constructor via the parameter object.

Answer 3

You can go with fluent interfaces: Building big, immutable objects without using constructors having long parameter lists

See also:

• Constructor Parameters - Rule of Thumb

• Having one request object as a Method Signature parameter, which constitute all the required parameters

Answer 4

如何拥有一个支持getter的抽象基类，但没有为类的所有属性设置setter，派生密封的“immutable”类，其构造函数接受基类对象，以及派生的可变类，其中包含所有属性的setter？