but the Bloch version constructs it in one chain of calls and is thus immutable

@codeslubber Bloch's builder pattern is nice but is even more verbose. What would I gain? @Paul Woitaschek This is for Java interop. Currently we construct the object by calling empty constructor and then mutating it all over the place by calling setters. That's what the

DogBuilder

would be used for.

oh well @poohbar we clearly have nearly opposite orientations, patterns don’t need to justify their existence to me by their ability to decrease LOC counts.. one of the reasons that Bloch was so popular (and why I liked it) is not just the road to immutable construction, but clear readable construction, since Java does not have named arguments, it also increased readability.. when I was using that pattern all the time, btw, I had a bunch of IntelliJ shortcuts that made creating new Builders go really fast..

I think Bloch's builders are valuable if you need to perform some form of validation before you build the object. I don't need that as the values are validated outside of the context of the class. So it's just a dumb value holder. To me:

DogBuilder().age(2).name("Spotty");

is just as readable as:

DogBuilder db = new DogBuilder();
db.setAge(2);
db.setName("Spotty");

I value your opinion, what do you think?

There is no need to validate the object before building

I have a need to validate the object before construction because I need to collect all invalid input and tell the user what to fix. #realworld

@poohbar we also have visited the realworld (unless you were referring to the MTV show there), and validation and object construction are usually kept separate. No one was saying build invalid objects. Certainly FP and favoring immutability would say users providing input and building object graphs that work should be treated as separate problems.