Implement Pizza Topping DecoratorseasyImplement Pizza Topping Decorators
Picture a pizza counter where the order starts plain and each requested topping is placed on whatever is already there. Cheese does not need to know whether it sits on a plain pizza or on top of pepperoni; it simply adds its own price and name to the pizza beneath it.
Your task is deliberately focused: implement only ToppingDecorator, CheeseDecorator, PepperoniDecorator, and MushroomDecorator. The Pizza contract, PlainPizza, and the PizzaOrder test harness are already implemented in the starter code.
All decorators must satisfy the same Pizza contract:
ToppingDecorator(inner)stores the wrappedPizzaand forwardscost()anddescription()unchanged.CheeseDecoratoradds1.50and appends", cheese".PepperoniDecoratoradds2.00and appends", pepperoni".MushroomDecoratoradds1.00and appends", mushrooms".
Each concrete topping should build on the values returned by the pizza it wraps. That is what allows toppings to be reordered or repeated without any topping knowing the whole order.
The provided PizzaOrder manages the chain for the tests:
- A new order contains a
5.00plain pizza described as"Plain pizza". addTopping(kind)accepts"cheese","pepperoni", or"mushrooms", up to six toppings.removeLastTopping()drops only the outermost topping.cost()anddescription()read from the current outermost layer.toppingCount()reports the number of toppings.summary()returns"<description> | $<cost>"with two decimal places.reset()returns to a plain pizza and reports how many toppings were removed.
Toppings may repeat, and every layer counts. Double cheese costs 8.00 and produces "Plain pizza, cheese, cheese". The examples call PizzaOrder because it is the public harness, but your code belongs only in the four marked decorator classes.
Example 1:
Input:
Output:
Explanation: A new order is a plain pizza, so the cost and the description both come from the base component and no toppings are counted.
Example 2:
Input:
Output:
Explanation: Cheese and then pepperoni add two layers. Each layer adds its own price to whatever the layer beneath it reported, so 5.00 becomes 6.50 and then 8.50.
Constraints
kindis a lowercase word of at most20characters.- At most
6toppings are on one order. - At most
100calls in total are made across all methods.
Starter Code
Only the decorator classes are unfinished. Define each complete class at its marked location. The shared contract, base component, and public test harness are already implemented; do not rewrite them.
How the design is graded
needs 7/10 to pass- Shared decorator base
Full marks when `ToppingDecorator` implements `Pizza`, stores the wrapped pizza, and delegates both `cost` and `description` by default. Lose points heavily when it creates a new plain pizza, stores a topping list, or hard-codes a total.
- Topping-specific behavior
Full marks when cheese adds 1.50 and `, cheese`, pepperoni adds 2.00 and `, pepperoni`, and mushrooms add 1.00 and `, mushrooms`, always building on the wrapped pizza's answers. Lose points for incorrect prices, labels, or returning only the topping's own value.
- Composable independent layers
Full marks when every concrete decorator can wrap any `Pizza`, repeated toppings are charged and named repeatedly, and description order emerges from the chain without inspecting concrete types. Lose points for special-casing combinations, mutating the supplied harness, or printing to stdout.
Passing every test is not enough on its own. A submission is accepted only when the design also clears the bar.
| Call | Returns |
|---|---|
| new PizzaOrder() | null |
| description() | "Plain pizza" |
| cost() | 5 |
| toppingCount() | 0 |
A new order is a plain pizza, so the cost and the description both come from the base component and no toppings are counted.
Run checks these cases. Submit also runs a larger hidden set.