creational
Builder
Separate the construction of a complex object from its representation so the same process can create different representations.
Constructors buckle under complexity. An object with a dozen fields — several optional, a few boolean — forces you into either a telescoping set of overloaded constructors or a single constructor whose call site is an unreadable row of positional arguments where true, false, true means nothing to the reader. Builder replaces that with a fluent, step-by-step assembly that names every value and validates the result before the object ever exists.
Ordering a custom pizza — you pick crust, sauce, toppings one by one. The kitchen only bakes it once you say done.
Key Concepts
1
A Builder class collects parameters one at a time through chained setter methods, each returning the builder itself so calls can be strung together. Required values go in the builder's constructor; optional ones get defaults and are overridden only when needed. A final build() call runs any cross-field validation and hands back the finished object. Because the target's own constructor is private and takes the builder, the only way to create one is through the builder, and the result can safely be immutable.
build()
2
It is the right tool when an object has many optional parameters, when construction needs multiple steps or validation, or when you want immutable objects that are still pleasant to configure. Java's StringBuilder, HTTP client request builders, and query builders all follow this shape. The cost is boilerplate — every field appears in both the object and the builder — though Lombok's @Builder or records with companion builders remove most of it. For an object with two or three fields, a plain constructor is simpler and Builder is overkill.
StringBuilder@Builder