[ Seminars ] [ Seminars on CD ROM ] [ Consulting ]
The use of layered objects to
dynamically and transparently add responsibilities to individual objects is
referred to as the decorator pattern.
Add Comment
Used when subclassing creates too many
(& inflexible) classes
Add Comment
All decorators that wrap around the
original object must have the same basic interface
Add Comment
Dynamic proxy/surrogate?
Add Comment
This accounts for the odd inheritance
structure
Add Comment
Tradeoff: coding is more complicated when
using decorators
Add Comment
Consider going down to the local coffee
shop, BeanMeUp, for a coffee. There are typically many different drinks
on offer -- espressos, lattes, teas, iced coffees, hot chocolate to name a few,
as well as a number of extras (which cost extra too) such as whipped cream or an
extra shot of espresso. You can also make certain changes to your drink at no
extra cost, such as asking for decaf coffee instead of regular coffee.
Add Comment
Quite clearly if we are going to model
all these drinks and combinations, there will be sizeable class diagrams. So for
clarity we will only consider a subset of the coffees: Espresso, Espresso Con
Panna, Café Late, Cappuccino and Café Mocha. We'll include 2
extras - whipped cream ("whipped") and an extra shot of espresso; and three
changes - decaf, steamed milk ("wet") and foamed milk ("dry").
Add Comment
One solution is to create an individual
class for every combination. Each class describes the drink and is responsible
for the cost etc. The resulting menu is huge, and a part of the class diagram
would look something like this:
Add Comment
Here is one of the combinations, a simple
implementation of a Cappuccino:
Add Comment
class Cappuccino:
def __init__(self):
self.cost = 1
self.description = "Cappucino"
def getCost(self):
return self.cost
def getDescription(self):
return self.description
The key to using this method is to
find the particular combination you want. So, once you've found the drink you
would like, here is how you would use it, as shown in the CoffeeShop class in
the following code:
Add Comment
#: cX:decorator:nodecorators:CoffeeShop.py
# Coffee example with no decorators
class Espresso: pass
class DoubleEspresso: pass
class EspressoConPanna: pass
class Cappuccino:
def __init__(self):
self.cost = 1
self.description = "Cappucino"
def getCost(self):
return self.cost
def getDescription(self):
return self.description
class CappuccinoDecaf: pass
class CappuccinoDecafWhipped: pass
class CappuccinoDry: pass
class CappuccinoDryWhipped: pass
class CappuccinoExtraEspresso: pass
class CappuccinoExtraEspressoWhipped: pass
class CappuccinoWhipped: pass
class CafeMocha: pass
class CafeMochaDecaf: pass
class CafeMochaDecafWhipped:
def __init__(self):
self.cost = 1.25
self.description = \
"Cafe Mocha decaf whipped cream"
def getCost(self):
return self.cost
def getDescription(self):
return self.description
class CafeMochaExtraEspresso: pass
class CafeMochaExtraEspressoWhipped: pass
class CafeMochaWet: pass
class CafeMochaWetWhipped: pass
class CafeMochaWhipped: pass
class CafeLatte: pass
class CafeLatteDecaf: pass
class CafeLatteDecafWhipped: pass
class CafeLatteExtraEspresso: pass
class CafeLatteExtraEspressoWhipped: pass
class CafeLatteWet: pass
class CafeLatteWetWhipped: pass
class CafeLatteWhipped: pass
cappuccino = Cappuccino()
print (cappuccino.getDescription() + ": $" +
´cappuccino.getCost()´)
cafeMocha = CafeMochaDecafWhipped()
print (cafeMocha.getDescription()
+ ": $" + ´cafeMocha.getCost()´)
#:~And here is the corresponding
output:
Add Comment
Cappucino: $1.0Cafe Mocha decaf whipped cream: $1.25
You
can see that creating the particular combination you want is easy, since you are
just creating an instance of a class. However, there are a number of problems
with this approach. Firstly, the combinations are fixed statically so that any
combination a customer may wish to order needs to be created up front. Secondly,
the resulting menu is so huge that finding your particular combination is
difficult and time consuming.
Add Comment
Another approach would be to break the
drinks down into the various components such as espresso and foamed milk, and
then let the customer combine the components to describe a particular coffee.
Add Comment
In order to do this programmatically, we
use the Decorator pattern. A Decorator adds responsibility to a component by
wrapping it, but the Decorator conforms to the interface of the component it
encloses, so the wrapping is transparent. Decorators can also be nested without
the loss of this transparency.
Add Comment
Methods invoked on the Decorator can in
turn invoke methods in the component, and can of course perform processing
before or after the invocation.
Add Comment
So if we added getTotalCost() and
getDescription() methods to the DrinkComponent interface, an
Espresso looks like this:
Add Comment
class Espresso(Decorator):
cost = 0.75f
description = " espresso"
public Espresso(DrinkComponent):
Decorator.__init__(self, component)
def getTotalCost(self):
return self.component.getTotalCost() + cost
def getDescription(self):
return self.component.getDescription() +
description
You combine the components to
create a drink as follows, as shown in the code below:
Add Comment
#: cX:decorator:alldecorators:CoffeeShop.py
# Coffee example using decorators
class DrinkComponent:
def getDescription(self):
return self.__class__.__name__
def getTotalCost(self):
return self.__class__.cost
class Mug(DrinkComponent):
cost = 0.0
class Decorator(DrinkComponent):
def __init__(self, drinkComponent):
self.component = drinkComponent
def getTotalCost(self):
return self.component.getTotalCost() + \
DrinkComponent.getTotalCost(self)
def getDescription(self):
return self.component.getDescription() + \
' ' + DrinkComponent.getDescription(self)
class Espresso(Decorator):
cost = 0.75
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class Decaf(Decorator):
cost = 0.0
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class FoamedMilk(Decorator):
cost = 0.25
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class SteamedMilk(Decorator):
cost = 0.25
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class Whipped(Decorator):
cost = 0.25
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class Chocolate(Decorator):
cost = 0.25
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
cappuccino = Espresso(FoamedMilk(Mug()))
print cappuccino.getDescription().strip() + \
": $" + ´cappuccino.getTotalCost()´
cafeMocha = Espresso(SteamedMilk(Chocolate(
Whipped(Decaf(Mug())))))
print cafeMocha.getDescription().strip() + \
": $" + ´cafeMocha.getTotalCost()´
#:~This approach would certainly
provide the most flexibility and the smallest menu. You have a small number of
components to choose from, but assembling the description of the coffee then
becomes rather arduous.
Add Comment
If you want to describe a plain
cappuccino, you create it with
plainCap = Espresso(FoamedMilk(Mug()))
Creating
a decaf Café Mocha with whipped cream requires an even longer
description.
Add Comment
The previous approach takes too long to
describe a coffee. There will also be certain combinations that you will
describe regularly, and it would be convenient to have a quick way of describing
them.
Add Comment
The 3rd approach is a mixture of the
first 2 approaches, and combines flexibility with ease of use. This compromise
is achieved by creating a reasonably sized menu of basic selections, which would
often work exactly as they are, but if you wanted to decorate them (whipped
cream, decaf etc.) then you would use decorators to make the modifications. This
is the type of menu you are presented with in most coffee shops.
Add Comment
Here is how to create a basic selection,
as well as a decorated selection:
#: cX:decorator:compromise:CoffeeShop.py
# Coffee example with a compromise of basic
# combinations and decorators
class DrinkComponent:
def getDescription(self):
return self.__class__.__name__
def getTotalCost(self):
return self.__class__.cost
class Espresso(DrinkComponent):
cost = 0.75
class EspressoConPanna(DrinkComponent):
cost = 1.0
class Cappuccino(DrinkComponent):
cost = 1.0
class CafeLatte(DrinkComponent):
cost = 1.0
class CafeMocha(DrinkComponent):
cost = 1.25
class Decorator(DrinkComponent):
def __init__(self, drinkComponent):
self.component = drinkComponent
def getTotalCost(self):
return self.component.getTotalCost() + \
DrinkComponent.getTotalCost(self)
def getDescription(self):
return self.component.getDescription() + \
' ' + DrinkComponent.getDescription(self)
class ExtraEspresso(Decorator):
cost = 0.75
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class Whipped(Decorator):
cost = 0.50
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class Decaf(Decorator):
cost = 0.0
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class Dry(Decorator):
cost = 0.0
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
class Wet(Decorator):
cost = 0.0
def __init__(self, drinkComponent):
Decorator.__init__(self, drinkComponent)
cappuccino = Cappuccino()
print cappuccino.getDescription() + ": $" + \
´cappuccino.getTotalCost()´
cafeMocha = Whipped(Decaf(CafeMocha()))
print cafeMocha.getDescription() + ": $" + \
´cafeMocha.getTotalCost()´
#:~You can see that creating a
basic selection is quick and easy, which makes sense since they will be
described regularly. Describing a decorated drink is more work than when using
a class per combination, but clearly less work than when only using decorators.
Add Comment
The final result is not too many classes,
but not too many decorators either. Most of the time it's possible to get away
without using any decorators at all, so we have the benefits of both approaches.
Add Comment
What happens if we decide to change the
menu at a later stage, such as by adding a new type of drink? If we had used the
class per combination approach, the effect of adding an extra such as syrup
would be an exponential growth in the number of classes. However, the
implications to the all decorator or compromise approaches are the same - one
extra class is created.
Add Comment
How about the effect of changing the cost
of steamed milk and foamed milk, when the price of milk goes up? Having a class
for each combination means that you need to change a method in each class, and
thus maintain many classes. By using decorators, maintenance is reduced by
defining the logic in one place.
Add Comment