skip to content

Builder

11 roadmaps6 questions

Assemble a complex object step by step so construction is readable and the result can be immutable. It is the standard answer to the telescoping-constructor problem and to constructors where required and optional parameters have blurred together.

part ofSoftware design & architectureoverview, primer and where to startread it →
on this pageshow

explore

questions

6

What problem does the Builder design pattern solve, and how is it better than a constructor that takes many parameters?

level: juniorimportance: must knowfreq 78%

answer

  1. telescoping constructor
  2. named steps beat positional args
  3. optional fields simply omitted
  4. build() = validate + freeze
  5. same-typed neighbours swap silently

basics

~20 s

Builder replaces a long constructor argument list. You set values one named step at a time, skipping the ones you do not need, then call build() to get the finished object. It is easier to read and harder to mix arguments up.

solid answer

~50 s

When a class has many fields, especially optional ones, the usual fallback is a chain of overloaded constructors — each adding one more parameter (the "telescoping constructor"). That is unreadable at the call site (`new Report(t, a, null, null, true, false)`), and any two adjacent parameters of the same type can be swapped without the compiler noticing. Builder separates construction from the finished object: a mutable helper collects values through named, order-independent steps, then `build()` validates everything and produces the product in one shot. Benefits: call sites read as documentation; optional fields are simply omitted rather than passed as nulls or defaults; the product can be fully immutable because it is populated once via a private constructor; cross-field invariants can be checked in `build()` before any object exists. The cost is extra code — a second class that must be kept in sync with the product's fields.

code

pseudocode · 9 lines
pseudocode
// telescoping: what do the trailing values mean?
report = new Report("Q3", "kim", null, null, true, false)

// builder: same data, self-documenting, order-independent
report = Report.builder()
               .title("Q3")
               .author("kim")
               .includeToc(true)
               .build()   // validates, then creates the immutable product

go deeper

for a junior

Name the telescoping-constructor problem, show that steps are named and optional ones can be skipped, and mention build() as the final call.

for a middle

Add immutability (product fields are final, populated once) and validation in build(), and contrast with the setter/JavaBeans style and its half-built-object window.

for a senior

Discuss the cost (duplicated field list, sync burden), when named/default arguments make builders redundant, and the difference between the fluent-builder idiom and the GoF Director-driven Builder.

for a principal

Frame it as an API-evolution decision: builders let a public API add optional parameters without breaking callers or exploding overloads, and set team-level guidance on the threshold (parameter count, optionality, immutability requirement) at which a builder is warranted.

### The starting problem Suppose you model a `Report` with fields: title, author, footer, page size, watermark, whether to include a table of contents, and a locale. Most of these are optional. Using ordinary constructors you have two bad options. **Option A — telescoping constructors.** You write one constructor per plausible combination: ``` Report(title) Report(title, author) Report(title, author, footer) Report(title, author, footer, pageSize) ... ``` Each overload delegates to the next larger one, filling defaults. This is called a *telescoping constructor* because the overloads nest like sections of a telescope. Problems: - The number of sensible overloads grows combinatorially; you can only support one linear ordering of optionality. - A call site like `new Report("Q3", "kim", null, null, true, false, null)` is unreadable — you cannot tell what `true` means without opening the class. - Two neighbouring parameters of the *same type* (two strings, two booleans, two ints) can be passed in the wrong order and still compile. This is a silent, runtime-only bug. **Option B — no-arg constructor plus setters (the "JavaBeans" style).** You create an empty object and mutate it: ``` var r = new Report(); r.setTitle("Q3"); r.setAuthor("kim"); ``` This reads better, but now: (1) the object exists in a half-built, invalid state between the constructor and the last setter — anything that reads it in between sees garbage; (2) the class cannot be immutable, because it must expose setters forever; (3) there is no single place to check rules that involve several fields at once. ### What Builder does Builder introduces a **separate, temporary object** whose only job is to accumulate the arguments. The product's own constructor is private and takes the builder (or the fully assembled value set) in one call. Roles, in the classic vocabulary: - **Product** — the complex object being created (`Report`). - **Builder** — the object that collects the parts, exposing one method per part. - **build() / getResult()** — the terminal step that validates and hands back the finished product. Because each step is a *named method*, the call site becomes self-documenting and order-independent: ``` Report.builder() .title("Q3") .author("kim") .includeToc(true) .build(); ``` Anything you do not mention keeps its default. Swapping two same-typed values is now a naming mistake you can see, not a positional accident. ### Fluency is a convenience, not the pattern Each step method typically `return this` so calls can be chained — this is the *fluent interface* idiom. It is what makes builders pleasant, but it is not what makes them a Builder: a builder with plain `void` setters is still a Builder. Conversely, fluent setters *on the product itself* are **not** a Builder — they mutate the real object and give up immutability and single-point validation. ### Immutability and validation, the two real payoffs Because the product is constructed exactly once, at the end: - All its fields can be final/read-only. Immutable objects are safe to share across threads, safe to use as map keys, and cannot be corrupted after a validity check. - `build()` is the natural home for checks that span fields (`endDate` after `startDate`; "if `watermark` is set, `pageSize` must not be null"). With setters, each setter sees only its own field and cannot know whether the object as a whole is valid yet. - The invalid object never exists at all — you fail before construction rather than after. ### Costs and when to skip it A builder duplicates the product's field list, so every new field is edited in two places (code generators, annotation processors, or records/data classes reduce this). For a class with two or three mandatory fields and no optionals, a plain constructor is clearer — Builder is machinery you pay for and should be justified by parameter count, optionality, or the need for immutability. Languages with **named arguments and default values** (Python, Kotlin, C#, Swift) already solve the readability half of the problem, which is why hand-written builders are far more common in languages that lack them.

  • If a language supports named arguments with default values, is Builder still useful?
    Often not, for the readability problem — `createReport(title = "Q3", includeToc = true)` already reads well. Builder still earns its place when construction is spread across code (values gathered in a loop, or in different layers), when you need a validated terminal step, when you want to hand a partially configured builder around as a template, or when the same steps must produce different representations.
  • Is a fluent setter chain on the object itself the Builder pattern?
    No. `obj.setA(1).setB(2)` mutates the real object, so it can never be immutable, it is observable in a half-built state, and there is no single point to validate. Builder's defining trait is that a *separate* object accumulates the parts and the product is created once.

A sandwich order slip: you tick the boxes you want in any order and hand the slip over; the sandwich is made once, at the end. Passing seven positional ingredients across a noisy counter — half of them 'none' — is the telescoping constructor.

saying these in an interview costs you the question

  • Claiming Builder's purpose is 'to make code fluent' — chaining is an idiom, the purpose is separating construction from the product
  • Calling fluent setters on the product itself a Builder
  • Saying Builder makes object creation faster — it usually allocates one extra object
  • Assuming every class with many fields needs a builder, regardless of optionality or immutability
  • Confusing Builder with Factory: Builder is about *how* a single complex object is assembled, not about *which* class to instantiate

context

resolving links…

open as a page

How does the Builder pattern let you create fully immutable objects with validated invariants, and why is that hard to achieve with a no-arg constructor plus setters?

level: middleimportance: must knowfreq 62%

basics

~20 s

The builder holds the values while you fill them in; the real object is created only once, at build(), through a private constructor. So the product needs no setters and can be immutable, and build() is a single place to check rules that involve several fields together.

open as a page

How does the Builder pattern differ from Factory Method and Abstract Factory, and how would you decide which one a given creation problem calls for?

level: middleimportance: should knowfreq 55%

basics

~20 s

Factory Method and Abstract Factory answer "which class do I create?" and do it in one call. Builder answers "how do I assemble this one complicated object?" across many calls. Use a factory to hide the concrete type; use a builder for many optional parts.

open as a page

The Gang of Four describe Builder as 'separate the construction of a complex object from its representation so that the same construction process can create different representations', with a Director driving an abstract Builder interface. How does that differ from the popular fluent nested-class builder, and when does the original form still matter?

level: seniorimportance: should knowfreq 40%

basics

~20 s

The fluent builder mainly names optional parameters for one class. The original Builder has an interface with several implementations plus a Director that calls the steps in a fixed order, so one construction process can produce different outputs — for example the same document walk emitting HTML or plain text.

open as a page

In a builder, how do you guarantee that required parameters were actually supplied, and what are the trade-offs between checking in build() at runtime and using a staged (step) builder that enforces it at compile time?

level: seniorimportance: should knowfreq 32%

basics

~20 s

Simplest: take required values in the builder's constructor or factory method, and check the rest in build(), throwing if something is missing. Stronger: a staged builder, where each step returns a different type that only exposes the next required step, so forgetting one will not compile.

open as a page

When is the Builder pattern the wrong choice, and what alternatives deliver the same benefits with less machinery?

level: principalimportance: nice to knowfreq 24%

basics

~20 s

Skip Builder when a class has few, mostly required fields, or when the language already has named arguments with defaults. Builders duplicate the field list, hide missing values until runtime, and a reused builder can leak state from one product into the next.

open as a page