Builder

The two pieces: a Product and its Builder

A Builder setup has just two moving parts. The Product is the thing you actually want (the finished Burger). The Builder is a small helper object that collects your choices and then hands you the finished product:

• The Builder holds the choices so far. As you call .addCheese() or .addBacon(), the builder just records that choice inside itself. Nothing is finished yet — you're still gathering ingredients.
• Each step returns `this`. Every method ends by returning the builder itself, so you can immediately call the next method on it. That's the trick that lets the calls chain into one readable line — it's called a fluent interface.
• `build()` returns the finished Product. The very last call takes everything the builder gathered and constructs the real Burger from it, then hands it back. Ideally the returned burger is immutable — done and unchangeable — so nobody can quietly alter it afterwards.

class BurgerBuilder {
  private parts: string[] = ["bun-bottom"];   // bun is always there

  addPatty()  { this.parts.push("patty");   return this; }  // return this →
  addCheese() { this.parts.push("cheese");  return this; }  // lets calls chain
  addBacon()  { this.parts.push("bacon");   return this; }

  build(): Burger {                            // finish → hand back the product
    this.parts.push("bun-top");
    return new Burger(this.parts);
  }
}

// Reads like an order: patty, cheese, bacon — done.
const burger = new BurgerBuilder()
  .addPatty()
  .addCheese()
  .addBacon()
  .build();

Notice how you only mention the parts you want. No cheese? Just don't call .addCheese(). Want two patties? Call .addPatty() twice. The order is up to you, and every line says exactly what it does — there is no row of mystery booleans to decode.

The Director: a helper that runs a known recipe

Sometimes the same combination of steps gets used over and over — a Classic Cheeseburger is always bun, patty, cheese, sauce. Instead of making every caller remember that recipe, you can wrap it in a Director: a small helper whose job is to run a fixed sequence of builder steps for you.

class BurgerDirector {
  // The Director knows the recipe; the caller doesn't have to.
  classicCheeseburger(b: BurgerBuilder): Burger {
    return b.addPatty().addCheese().addSauce().build();
  }
}

const burger = new BurgerDirector()
  .classicCheeseburger(new BurgerBuilder());   // one call → a preset burger

Now a caller who just wants the standard cheeseburger asks the Director for it and gets a finished burger — without knowing or repeating the individual steps. The Director is optional: you only reach for it when you have a few named presets worth naming. The prototype's two preset buttons (Classic Cheeseburger and Veggie Deluxe) are exactly this idea — one click runs a fixed recipe of builder steps.

Why the constructor way goes wrong

If you build the same burger with a plain constructor, you have to pass a value for every optional part in a fixed position: new Burger(true, true, false, true, false, true, false). Which flag is cheese? Which is bacon? You can't tell without opening the constructor and counting. Add one more topping later and every call site with that long argument list can silently break. The Builder makes each choice named and optional, so the code stays readable no matter how many toppings exist. Flip the prototype's Constructor way ↔ Builder way switch to feel the difference on the very same burger.

Reach for a Builder when construction gets messy

The Builder shines whenever making an object with a plain constructor would be confusing, error-prone, or rigid:

• Many optional fields. When an object has lots of parts that may or may not be present, a Builder lets callers set only the ones they want by name instead of passing a long line of true/false/null.
• The object should be immutable once built. Gather all the choices in the builder, then produce a finished object that can't be changed afterwards — a very common and safe pattern.
• Step-by-step or validated assembly. Config objects, HTTP request builders, SQL query builders, StringBuilder, and test-data builders all assemble a result piece by piece, sometimes checking rules before build() hands it back.
• A few named presets exist. When common combinations repeat (a Classic Cheeseburger), a Director wraps the recipe so callers get the preset in one call.