Java Reference
In-Depth Information
to eat pizza. However, it was catastrophic for our system because of our design
rule: If an add‐on option changes the price of a product, it should be added as a
new product. Because each topping had a different price, we needed to calculate
all the combinations of toppings and enter a new pizza to the menu for each
combination.
As you know,
n!
algorithms grow large quickly, which in this case would have
resulted in a long list of pizzas after only a few combinations. Because this was
not acceptable, we suggested to the client that he enter several pizzas with a i xed
number of toppings (1 topping, 2 topping, 3 topping), and he could add a note to
the order to record the customer's choice of topping. With this solution, we could
shorten the list from
n!
to
n
.
Still, this solution was not really reasonable. Because the system was already
up and running, we needed to i nd a way to i x it without breaking other parts.
We needed a way to add functionality at run time. We needed to “decorate” the
existing pizza object with toppings. Clearly, the answer was to implement the
decorator pattern. And that is what we did. Each topping the customer chose
wrapped the pizza object in a similar way to the example used in the
Head First
Design Patterns
book.
Decorator Class Diagram
As is seen in the class diagram in Figure 7-1, the decorator pattern introduces some boilerplate code
to an existing class hierarchy. T he pattern introduces a shared interface between the target class and
the decorator. The decorator must have a reference to an instance of this interface.
Component
+
operation()
ConcreteComponent
Decorator
- component
+ operation()
+
operation()
ConcreteDecorator
+ operation()
FIGURE 7-1:
Class diagram of the decorator pattern
