DevOps Articles

Why Builder Is Often an Antipattern and How to Replace it With Fluent Build

Unfortunately, it's often misunderstood and incorrectly applied, which results to runtime errors. Let's remember the purpose of Builder: set only necessary fields in some object and keep remaining fields set to default values.

A traditional Builder class would look like this: One important observation: every setter returns this and this in turn allows users of this call to invoke every method available in builder.

To do this, we can return dedicated interfaces instead of this and let Builder implement all these interfaces: Huh.

But, much more importantly, we can omit whole setters and mutable fields boilerplate in the builder, which significantly reduces the amount of code.