Immutability and readability

Question

So, I read Joshua Bloch's "Effective Java" and noticed two points that I really met in my work.

Point 1: Create customization methods to make the code more readable. In his example, we have a class with a ridiculous huge constructor. When people create an instance of a class, it's hard to say what happens to all the parameters. Thus, he proposed creating a minimalist constructor and setting customization 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 (e);
clazz.setGumballs (g);

Which, as a huge proponent of readable code, I really liked.

Point 2: In general, he suggested having immutable classes. He delves deeply into why unstable classes are much better than classes that can be in several different states. I can definitely say that he sold me this idea, and I can’t wait for most of the classes I'm writing from now to be immutable except ....

What happens when you have an immutable class with a huge constructor? You cannot make setter methods for it; which breaks immutability. I tried to slip through the rest of the book, but I don't think he covered the solution for this.

There is the possibility of using one-time setter methods, but only the fact that the setter method is available for a class that is supposedly immutable is discouraging, even if it just throws an exception if you try it in later times.

Does anyone have any good ideas on how to deal with this problem? I am currently facing this problem at work, where I have an Immutable class with a huge constructor that I would like to reorganize into something more readable without violating immutability.

Answer 1

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

In the second issue of Effective Java, the flea, clause 2 illustrates this for an immutable class. Key ideas:

• The builder has a variable field for each option.
• The builder passes itself as the only argument to the constructor of immutable classes.

Answer 2

Enter a parameter object , maybe? This seems to be a problem, but maybe useful. The parameter object does not require any methods; it just stores the data and you set it up instead of your real class. Then your real class is initialized in the constructor via the parameter object.

Answer 3

You can freely work with interfaces: Creating large immutable objects without using constructors with long lists of parameters

See also:

• Constructor Options - Thumb Rule

• The presence of one request object as a parameter of the Signature method, which is all the necessary parameters

Answer 4

How about having a base base class that supports getters but does not set all class attributes to a derived closed "immutable" class whose constructor accepts a base class object and a derived mutable class that includes setters for all properties?