Head First Design Patterns - Decorator Pattern

Question

I'm reading the chapter on the Decorator Pattern in Head First Design Patterns. They use a coffee ordering system as an example to teach the pattern. While the Decorator Pattern seems a useful pattern, it does not seem appropriate for a coffee ordering system.

Wouldn't it be simpler to just have a table (or list or some such) of items (flavors, condiments, etc.) and costs (possibly with modifications for size)? When customer orders a Dark Roast with Mocha and Whip, create a list of items, then lookup and total the costs. Why go through all the class overhead? Adding a new item and cost to a list seems simpler than creating a new class.

Am I missing something basic? Should I be ignoring the example and just focus on the pattern? Should I be reading another book?

Answer 1

Its just an example to illustrate the principle.

But please feel free to share your code here so we can comment on it.

Answer 2

The point was that the decorator – in contrast to your list – can apply arbitrary transformations on the price.

For example, have a look at the SpecialOfTheDayDrink which has a 20% discount:

class SpecialOfTheDayDrink extends Beverage {
    private final Beverage theDrink;

    public SpecialOfTheDayDrink(Drink theDrink) {
        this.theDrink = theDrink;
    }

    @Override
    public double cost() {
        return theDrink.cost() * 0.8;
    }
}

How would you model this?

(Admittedly, restricting the example in the book to a CondimentDecorator is misleading because here all cost calculations take the same form, as does the description. Other patterns would be more appropriate to model this.)

Answer 3

As Martin mentions it's just an example to illustrate the principle so you shouldn't get too hung up on whether it's appropriate.

A better practical example of usage of the Decorator pattern IMHO is within the Java JDK: The java.io package contains numerous InputStream and OutputStream implementations, each of which is typically constructed by passing in (i.e. wrapping or decorating) another InputStream / OutputStream instance. Hence it is possible to create a FileOutputStream and decorate it with a GZipOutputStream in order to write compressed data to a file.

Answer 4

Decorator pattern is a pattern to add new functionality/feature to your existing object. You can google for many more examples on decorator pattern. You can start @ http://en.wikipedia.org/wiki/Decorator_pattern

Answer 5

Reading your question, I remember thinking the exact same thing when I read the chapter. Even with the use of decorators, you're still going to have to add a lot of code whenever you add a new beverage to the menu.

There's also the matter that there isn't really much difference among the beverages. Mochas, dark roasts, decafs and so on just aren't different enough to justify defining a whole new class for each one. As far as the business of the coffee shop is concerned, the drinks don't differ in behaviour; they differ only when it comes to properties: name, size, condiments, price, discount and so on. "Same behaviour, differing properties" is a hint that those objects should probably be of the same class.

A real-world chain of cafes isn't going to tolerate a code update every time they add a new drink to the menu or change the prices of existing drinks (because real-world economics make real-world coffee prices fluctuate). foosion's right: the real-world way to implement this is to use an approach that's more data-driven. Adding a drink to the menu should be done by adding a new row to the data table. Changing prices for a drink should be done by changing the "price" column for that drink.

As for the use of the "Starbuzz Coffee" example in Head First Design Patterns, it was probably used because one of the cardinal rules of the Head First series is that its content be interesting and fun, and the authors probably felt that the equipment inventory example for decorators in the Gang of Four book would bore their readers.

[Edit: Wouldn't you know it -- someone beat me to the punch by five years, saying pretty much the same thing -- see Ravi Venkataraman's comment to this article.]