Head First Desin Patterns Chapter 3 Page 92 : Can anybody tell what is signifcance of having "CondimentDecorator" abtract decorator class which extends the abstract "Beverage" class. Why can't the concrete decorators extend the abstract "Beverage" class.
Without ever having seen the book in question, I'll take a stab at the answer anyhow. I assume it follows the standard set in the Gang of Four "Design Patterns" book.
The abstract CondimentDecorator class adds methods and fields that are common to all Decorators but not needed by plain Beverage subclasses. For instance, CondimentDecorator probably declares a constructor that takes the Beverage to decorate and stores it in an instance field.
Also, it cuts way down on the amount of typing needed for the subclasses if CondimentDecorator implemented all the methods of the Beverage class to just delegate the calls to the same methods in the decorated Beverage object. Then the various decorator classes can just override the methods for which they have specific needs. This becomes more important as the number of methods in the base Beverage class class increases.
Ryan [ May 09, 2005: Message edited by: Ryan McGuire ]
This chapter is online HERE and it makes a great impression for the book.
One difference I see between the decorator and the ConcreteComponent (on p 91) is that each decorator has a reference to the object being decorated. Is that enough reason to have the abstract decorator? Can you think of any other helper methods it might have to simplify calling down the chain of decorators or collecting their results?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
