Question about decorator pattern and the abstract decorator class?
Posted
by es11
on Stack Overflow
See other posts from Stack Overflow
or by es11
Published on 2010-01-06T22:24:54Z
Indexed on
2010/06/08
1:02 UTC
Read the original article
Hit count: 292
This question was asked already here, but rather than answering the specific question, descriptions of how the decorator pattern works were given instead. I'd like to ask it again because the answer is not immediately evident to me just by reading how the decorator pattern works (I've read the wikipedia article and the section in the book Head First Design Patterns).
Basically, I want to know why an abstract decorator class must be created which implements (or extends) some interface (or abstract class). Why can't all the new "decorated classes" simply implement (or extend) the base abstract object themselves (instead of extending the abstract decorator class)?
To make this more concrete I'll use the example from the design patterns book dealing with coffee beverages:
- There is an abstract component class called
Beverage
- Simple beverage types such as
HouseBlend
simply extendBeverage
- To decorate beverage, an abstract
CondimentDecorator
class is created which extendsBeverage
and has an instance ofBeverage
- Say we want to add a "milk" condiment, a class
Milk
is created which extendsCondimentDecorator
I'd like to understand why we needed the CondimentDecorator
class and why the class Milk
couldn't have simply extended the Beverage
class itself and been passed an instance of Beverage
in its constructor.
Hopefully this is clear...if not I'd simply like to know why is the abstract decorator class necessary for this pattern? Thanks.
Edit: I tried to implement this, omitting the abstract decorator class, and it seems to still work. Is this abstract class present in all descriptions of this pattern simply because it provides a standard interface for all of the new decorated classes?
© Stack Overflow or respective owner