Builder Pattern

Build a complex object step by step through a builder, so many optional parts do not turn into a constructor nobody can read.

Overview

Builder is a creational pattern from the Gang of Four book (Gamma, Helm, Johnson and Vlissides, *Design Patterns*, 1994). The idea: when an object takes many steps to assemble, put those steps on a separate builder object, and let the builder hand over the finished product at the end. The same sequence of steps can then produce different results, depending on which builder runs them.

In interviews the name covers two shapes. The GoF shape has a Director that knows the order of steps and a Builder interface with one method per step; different concrete builders produce different representations. The fluent shape, which Joshua Bloch popularized for Java in *Effective Java* (Item 2), has no director: the client chains setter-like methods on the builder and calls build(). Most interview questions mean the fluent one, and the strong answer knows both.

The pattern earns its place when a constructor would need many parameters, most of them optional, or when the product should be immutable once built.

The two shapes of the pattern

Who orders the steps — A Director — The client, by chaining calls
Why it exists — The same steps must produce different representations — One class has many optional parts
Builder interface — Shared by several concrete builders — One builder per product, often nested in it
Typical product — A document, a parse tree, a UI — A request, a configuration, a value object
What interviews usually mean — Rarely — Almost always

A fluent builder in Python that runs

The builder is mutable and collects the parts. The product is a frozen dataclass, so once built it cannot change. The two required values go into the builder's constructor; everything else is a chained call.

Where you meet it for real

Java java.net.http.HttpRequest.Builder — Obtained from HttpRequest.newBuilder(); each setter changes the builder and returns the same instance; build() returns a new immutable HttpRequest every time it is called
Python keyword arguments — A dataclass with defaults gives most of the readability of a builder for free; the builder still wins when validation spans several fields or construction happens in stages

What you will be able to do

Recognize the telescoping-constructor smell and replace it with a builder.
Write a fluent builder with required parts in the constructor, chained optional parts and one validating build().
Explain the GoF Director shape and when the extra layer pays off.
Enforce required fields three ways and say which one an interviewer should hear first.

Interview questions

What problem does Builder solve? Show the smell and the fix.
How do you make sure required fields are set before build()?
When does the GoF Director shape pay off?
How is Builder different from Factory Method and Abstract Factory?
Why pair a builder with an immutable product, and what does that mean for threads?