Explore Topics
🎁
Intent
Separate construction from representation
🏭 Builder Assembly Cockpit — Director (Classical) and Fluent (modern) side by side
Choose Concrete Builder:
Step 0 / 8
📜 Director.buildRoaster() recipe
·builder.buildCoolingTray();
·builder.buildExhaustSystem();
·builder.buildGasBurner();
·builder.buildInnerDrum();
·builder.buildMainBody();
·builder.buildMotor();
·builder.buildPlatform();
·builder.buildThermocouples();
🛠️ Assembling — Personal Roaster0 parts
Empty Roaster shell. Click ▶ Step to drive the Director through one builder.buildXxx() call.
Switch between Personal and Commercial — the Director's 8-step recipe is identical, but the Roaster it produces is completely different. Personal even skips one step (no-op) without breaking the recipe.
🎁
Intent
Separate construction from representation
Builder is a **creational** GoF pattern that separates **how** a complex object is constructed from **what** the object ultimately is. A single Director runs the same construction sequence; different Concrete Builders plug into that sequence and produce different Products. Build a House: the Director always calls `foundation → walls → roof → windows → garage`, but the StoneHouseBuilder produces a slate-roofed brick home with a garage, while the WoodHouseBuilder produces a cedar cabin on stilts with no garage at all.
Key Ideas
- **Construction** (the step sequence) is separated from **representation** (the final Product). The Director owns the sequence, the Builder owns the steps, the Product is the result.
- The **same** Director recipe drives **different** Concrete Builders to produce **different** Products — that is the pattern's defining mechanic.
- The Product never exists in a half-built state visible to the Client — the Builder returns it only after the last step (`getRoaster()` / `build()`).
- A Concrete Builder can **skip** a step (return immediately) — the same Director recipe can produce a Product that lacks one of the parts, without changing the Director.
Strengths
- ✦One Director, N Concrete Builders, N different Products — adding a new Product variant means a new ConcreteBuilder, no change to Director or Client.
- ✦The complex construction logic is encapsulated in one place (the Concrete Builder) — Client code stays a 3-line script: pick a Builder, hand it to the Director, collect the Product.
- ✦Final Product can be **immutable** — all fields can be `final`, set exactly once when the Builder hands them off.
Weaknesses
- △Three new classes for every Product family (Builder interface + N ConcreteBuilders + Director) before you write a single line of business logic.
- △For simple objects (a Point with two coordinates), a constructor is shorter, clearer, and faster.
- △The Director and the Builder both know the Product's shape — if the Product grows a new component, BOTH must change in lockstep.
Used in:A **House Construction** demo: a `ConstructionDirector` runs the 5-step recipe (foundation → walls → roof → windows → garage). Two Concrete Builders — `StoneHouseBuilder` and `WoodHouseBuilder` — plug in different materials at each step. WoodHouseBuilder also implements `buildGarage()` as a no-op because cabins do not have garages. Same recipe, two finished Houses that look nothing alike.
Code Snippets
Quiz
Intent Quiz
QUIZ 1/6Which statement best captures the **intent** of the Builder pattern?
Diagrams
Practice
Drag each class, interface, or expression into the Builder role it fills. Two items are traps — they belong to a DIFFERENT GoF pattern and should be sorted into the trap bucket.
EXERCISE 1/4interface RoasterBuilder { void buildCoolingTray(); void buildMotor(); ... Roaster getRoaster(); }
public static class Builder { /* static nested, fluent setters, build() */ }
class PersonalRoasterBuilder implements RoasterBuilder { /* small parts, no platform */ }
class CommercialRoasterBuilder implements RoasterBuilder { /* industrial parts, all 8 steps */ }
class Roaster { LinkedList<String> components; void add(String c); }
public final class Computer { private final String hdd, ram; /* immutable */ }
class Director { void buildRoaster(RoasterBuilder b) { b.buildCoolingTray(); ... b.buildThermocouples(); } }
main(): Builder b = new PersonalRoasterBuilder(); director.buildRoaster(b); Roaster r = b.getRoaster();
class LoggerSingleton { private static LoggerSingleton INSTANCE; }
interface ShapeFactory { Shape createShape(String type); }
Builder interface (declares construction steps)
ConcreteBuilder (implements steps for one variant)
Product (the resulting object)
Director (knows the construction algorithm / order)
Client (picks Builder, hands to Director)
NOT part of Builder (belongs to a different pattern)
Order the lines to build a Computer with the Fluent Builder: required HDD + RAM, optional GPU + Bluetooth, then build and use.
EXERCISE 2/4Drag the lines into the correct order.
.bluetooth(true) // optional via fluent setter
Computer dev = new Computer.Builder("2 TB", "64 GB") // required via Builder constructor
dev.displaySpec("Dev workstation"); // use the immutable Computer
.build(); // finalize → returns the immutable Computer
.graphicsCard(true) // optional via fluent setter
The Director is leaking state across builds — find the bug
EXERCISE 3/4Click on the line you think contains the bug, then press Confirm.
8 common myths about the Builder pattern — true or false?
EXERCISE 4/4Every Builder pattern implementation must have a Director class.
The Builder pattern solves the telescoping-constructor problem.
Builder and Abstract Factory are interchangeable — they solve the same problem.
In a Fluent Builder, the setter methods must return `this` to enable chaining.
Calling `build()` twice on the same Builder is always safe and returns the same Product.
A Concrete Builder can implement a step method as a no-op (do nothing).
The Builder pattern is structural, not creational.
The Fluent Builder requires the Product to be immutable.