AlgoMaster Logo
AlgoMasterImplement a Pizza Builder and Directormedium

Implement a Pizza Builder and Director

medium

A pizza shop needs to support two familiar ordering styles. Some customers want a named recipe with no fuss; others want to choose the crust, sauce, cheese, and toppings themselves. Both routes should assemble the same kind of Pizza, which makes one shared builder a natural fit.

Your task is to implement both PizzaBuilder and PizzaDirector. The Pizza product and the PizzaShop test harness are pre-implemented.

The builder must behave as follows (use the exact names from your language's starter code):

  • PizzaBuilder(size) stores the size and starts with crust "regular", sauce "tomato", cheese "mozzarella", and no toppings.
  • setCrust(value), setSauce(value), and setCheese(value) replace the corresponding choice.
  • addTopping(value) appends a topping and preserves insertion order.
  • Every configuration method returns the same builder instance so the director can chain recipe steps.
  • build() returns a new Pizza from the current state without clearing the builder.

The director must provide one method for each standard recipe:

  • buildMargherita(size) creates a fresh builder, applies the margherita recipe, and returns its pizza.
  • buildPepperoni(size) does the same for the pepperoni recipe.
  • buildVeggie(size) does the same for the veggie recipe.
  • The director must not store or reuse a builder between calls. Each method starts from a new PizzaBuilder(size) and finishes by calling build().

A pizza renders like this:

Pizza{size='medium', crust='regular', sauce='tomato', cheese='mozzarella', toppings=[basil]}

A pizza in progress starts with a regular crust, tomato sauce and mozzarella, and no toppings. The three standard recipes are fixed:

  • margherita has a regular crust, tomato sauce, mozzarella, and basil.
  • pepperoni has a thin crust, tomato sauce, mozzarella, then pepperoni and olives.
  • veggie has a whole wheat crust, pesto sauce, gouda, then mushrooms, peppers, onions and olives.

The provided shop keeps a separate builder for a custom pizza, validates recipe names and sizes, and asks your director to fulfill standard orders. Because each director method creates its own builder, a standard order cannot disturb a custom pizza already in progress.

The examples call PizzaShop because it is the public test harness. Your code changes belong only in PizzaBuilder and PizzaDirector.

Example 1:

Input:

Output:

Explanation: The director applies the margherita recipe to the size it was given and returns the finished pizza. Nothing about the shop had to be configured first.

Example 2:

Input:

Output:

Explanation: A custom pizza overrides all three defaults and collects three toppings, which appear in the order they were added.

Constraints

  • 1 <= value.length <= 20
  • 0 <= index <= 100
  • At most 10 toppings are added to one pizza.
  • At most 100 calls in total are made across all methods.

Starter Code

PizzaBuilder and PizzaDirector are unfinished. No templates are supplied: implement both types completely. Pizza and PizzaShop are already implemented; do not rewrite them.

How the design is graded

needs 7/10 to pass
  • Builder defaults and fluent updates

    Full marks when each builder stores its size, starts with regular crust, tomato sauce, mozzarella and a fresh topping list; setters replace one field; toppings append in order; and configuration methods return the same builder. Lose points for shared state, missing defaults, broken chaining, sorting, or overwriting toppings.

  • Director recipes and isolation

    Full marks when PizzaDirector implements all three recipes by creating a new PizzaBuilder per call, applying the specified values and toppings in order, and returning build(). Lose points when the director keeps a builder as state, reuses the shop's custom draft, or places recipe logic in PizzaShop.

  • Product creation

    Full marks when builder.build returns a new Pizza from the current builder state without clearing the draft, so repeated builds are independent snapshots. Lose points when build caches a Pizza, mutates the builder, or exposes shared topping state.

Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.

Hints

Loading...
CallReturns
new PizzaShop()null
order("margherita", "medium")"Pizza{size='medium', crust='regular', sauce='tomato', cheese='mozzarella', toppings=[basil]}"
builtCount()1

The director applies the margherita recipe to the size it was given and returns the finished pizza. Nothing about the shop had to be configured first.

Run checks these cases. Submit also runs a larger hidden set.