When a constructor takes too many parameters, the call site grows hard to read. A call like new Pizza(true, false, true, false, true, "cheese", 12) forces the reader back to the constructor definition to make sense of each argument. When some parameters are optional, a common workaround is to define several constructors with different parameter counts — the Telescoping Constructor anti-pattern. This is the backdrop for Builder.

Builder shows up when three limits arrive together: many parameters, some optional, and step-wise validation. With only one of the three, a simpler tool suffices — constructor overloading, a static factory method, setters. When all three coincide, Builder reads most clearly. If the language offers named and default parameters, however, the same limits ease and Builder’s role shrinks accordingly.

The Shared Intent

Builder carries three intents.

  • Step-wise creation — Objects are not built in one shot. They take shape through a sequence of method calls.
  • Parameter validation — Consistency checks happen at the moment all parameters are in place (build()). With a constructor, validation logic scatters across each parameter.
  • Immutable result — The final object emerges without setters, avoiding the partial-initialization state a setter-based bean creates.

The three intents converging in one pattern is what defines Builder. Drop one and a simpler tool fits better.

GoF Form vs Fluent Builder

The GoF formulation uses four roles: Director, Builder, ConcreteBuilder, Product.

Director decides the creation sequence and calls methods on the Builder interface. ConcreteBuilder implements that interface to produce the actual Product. Hand the same Director a different ConcreteBuilder and a different Product comes out. Producing different representations through the same construction process is the core of the GoF form.

In practice, the fluent builder Joshua Bloch organized in Effective Java Item 2 shows up more often.

Pizza pizza = new Pizza.Builder()
    .size(12)
    .cheese(true)
    .pepperoni(true)
    .build();

Director is gone. Builder exposes setter-shaped methods in a fluent chain. When build() is invoked, every parameter is in place, validation runs, and an immutable Product is returned.

The GoF form has its strength in producing multiple representations through the same procedure. The fluent builder has its strength in readability when the single object has many parameters. The fluent form dominates in practice.

Language Implementations

Each language expresses the same intent differently.

Java has the richest Builder ecosystem. Hand-written builders work fine, and Lombok’s @Builder automates the generation. @Builder.Default covers defaults; @Singular handles incremental additions to collections. The cost is a dependency on Lombok’s compile-time abstractions.

Python rarely needs an explicit Builder. dataclass plus defaults already covers most of the same ground.

@dataclass
class Pizza:
    size: int
    cheese: bool = False
    pepperoni: bool = False

The call site reads as Pizza(size=12, cheese=True). Many or optional parameters do not produce a Telescoping problem. Validation gathers in __post_init__. An explicit Builder class shows up only when validation is complex or fields depend on each other in steps.

TypeScript is similar. An object literal with an interface fills the same role.

interface PizzaOptions {
  size: number;
  cheese?: boolean;
  pepperoni?: boolean;
}

const pizza = new Pizza({ size: 12, cheese: true });

Optional fields use ?, and the caller passes a named object. A fluent builder is possible, but the object literal is shorter and clearer.

The richer the language’s support for named and default parameters, the smaller the room an explicit Builder needs.

Constructor, Static Factory Method, Builder

Comparing the three tools by parameter count and optionality clarifies the choice.

  • Few parameters (1–3) — Constructor. Adding another tool only adds noise.
  • Medium count with a need for naming — Static factory method (Pizza.cheesePizza() and the like).
  • Many parameters, some optional, with validation — Builder.

Effective Java Item 2 suggests a builder once there are four or more parameters with some optional. In practice, a more conservative rule — reach for Builder only when constructors and static factory methods clearly fall short — preserves simplicity.

The three are not mutually exclusive. A class often exposes both a static factory method and a builder. Stream.builder() is a familiar example.

When the Language Absorbs the Pattern

Two of Builder’s three limits — parameter count and optionality — can be absorbed into the language itself.

Kotlin’s named parameter plus default value is the canonical case.

data class Pizza(
    val size: Int,
    val cheese: Boolean = false,
    val pepperoni: Boolean = false
)

val pizza = Pizza(size = 12, cheese = true)

The call site reads as cleanly as a fluent builder, in less code. The Telescoping Constructor problem disappears at the syntax level. Scala’s case classes and Swift’s named arguments follow the same direction.

When validation is step-wise or depends on previous fields, Builder still has a place. But the simpler limits — parameter count and optionality — get resolved by named/default parameters, and Builder shrinks naturally.

This is one of the cases where a design pattern gets absorbed into language features over time. The pattern does not disappear; the problem it solved gets handled at the language level.

Conclusion

Builder is the choice when a constructor’s three limits — parameter count, optionality, and step-wise validation — meet at once. With only one of the three, a simpler tool fits better.

The choice narrows down to two questions.

  • Are there four or more parameters, with some optional, and does validation belong in one place? If so, Builder.
  • Does the language offer named and default parameters richly? If so, Builder’s place narrows to the cases where step-wise validation truly matters.

The GoF Director/Builder/Product form sees less use today; Effective Java’s fluent builder dominates. Pattern shapes evolve with the era and the language.

References

  • Factory — How Static Factory Method and Builder compare in the decision criteria
  • Singleton — getInstance as another form of static factory method
  • Joshua Bloch — Effective Java (3rd ed.), Item 2: Consider a builder when faced with many constructor parameters
  • GoF — Design Patterns: Elements of Reusable Object-Oriented Software (1994)