Win a copy of Real-World Software Development: A Project-Driven Guide to Fundamentals in Java this week in the Agile and Other Processes forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Liutauras Vilda
  • Knute Snortum
  • Bear Bibeault
  • Devaka Cooray
  • Jeanne Boyarsky
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • salvin francis
  • Tim Holloway
  • Piet Souris
  • Frits Walraven

Head First Book - Is the example for Decorator pattern useful ?

Tom Joe
Ranch Hand
Posts: 79
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The HF book uses Starbucks Coffee as an example for the Decorator pattern. Basically, everything is considered a Beverage (component). Beverage has getDescription() and cost() methods. We have four Beverages - HouseBlend, DarkRoast, Espresso and Decaf which have only cost() method. There is a CondimentDecorator interface which extends/implements Beverage and has only getDescription(). Beverage addons like Soy, Whip, Mocha etc. extend/implement the CondimentDecorator and they have getDescription() and cost() methods.

I understand that the author is trying to give a simple example which is easy to understand and remember. But, it seems odd to implement Decorator that way. Instead of using the Decorator pattern, can we let Beverage instances have a Map of Condiments which would store the condiments and their units (ex. double whip) ? I wonder if there is a better example. To the author's credit, they covered the JavaIO InputStream which also uses Decorator.

Why do I care about which example I use ?

I want to be able to remember a pattern by a short quick example. The Beverages example does not seem like it would be best solved by Decorator. So, it might be difficult to remember it that way. In contrast, the Strategy pattern is much easier to remember because of the example that was used to explain it.

Here it the Strategy example. Real and toy Ducks have fly and quack behavior. If we put those behaviors in Duck and make every duck inherit it, then some ducks will have unwanted behavior (Rubber duck will fly!). Moreover, we will have to make classes for different types of ducks that have essentially same fly behavior. A minor change to that fly behavior would require change in multiple classes. To overcome those problems, we represent a set of related behaviors with an interface and provide them to Ducks (Favor composition over inheritance). Hence, behavior can even be changed at run time. If your duck gets injured in the game, then its fly behavior can easily be changed from "fly fast normally" to "fly oddly due to injury". In short, Strategy pattern = Ducks fly and quack. It is likely that I will never forget the Strategy pattern this way, at least not for one year. The Duck example feels like a good candidate for Strategy. But, the Beverage example just does not feel like a good example for Decorator.
Hold that thought. Tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!