X: Decorators: dynamic type selection
The use of layered objects to
dynamically and transparently add responsibilities to individual objects is
referred to as the decorator pattern.
Used when subclassing creates too many
(& inflexible) classes
All decorators that wrap around the
original object must have the same basic interface
Dynamic proxy/surrogate?
This accounts for the odd inheritance
structure
Tradeoff: coding is more complicated when
using decorators
Basic decorator structure
A coffee example
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.
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").
Class for each combination
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:
Here is one of the combinations, a simple
implementation of a Cappuccino:
class Cappuccino {
private float cost = 1;
private String description = "Cappucino";
public float getCost() {
return cost;
}
public String getDescription() {
return 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:
//: cX:decorator:nodecorators:CoffeeShop.java
// Coffee example with no decorators
package cX.decorator.nodecorators;
import com.bruceeckel.test.UnitTest;
class Espresso {}
class DoubleEspresso {}
class EspressoConPanna {}
class Cappuccino {
private float cost = 1;
private String description = "Cappucino";
public float getCost() {
return cost;
}
public String getDescription() {
return description;
}
}
class CappuccinoDecaf {}
class CappuccinoDecafWhipped {}
class CappuccinoDry {}
class CappuccinoDryWhipped {}
class CappuccinoExtraEspresso {}
class CappuccinoExtraEspressoWhipped {}
class CappuccinoWhipped {}
class CafeMocha {}
class CafeMochaDecaf {}
class CafeMochaDecafWhipped {
private float cost = 1.25f;
private String description =
"Cafe Mocha decaf whipped cream";
public float getCost() {
return cost;
}
public String getDescription() {
return description;
}
}
class CafeMochaExtraEspresso {}
class CafeMochaExtraEspressoWhipped {}
class CafeMochaWet {}
class CafeMochaWetWhipped {}
class CafeMochaWhipped {}
class CafeLatte {}
class CafeLatteDecaf {}
class CafeLatteDecafWhipped {}
class CafeLatteExtraEspresso {}
class CafeLatteExtraEspressoWhipped {}
class CafeLatteWet {}
class CafeLatteWetWhipped {}
class CafeLatteWhipped {}
public class CoffeeShop extends UnitTest {
public void testCappuccino() {
// This just makes sure it will complete
// without throwing an exception.
// Create a plain cappuccino
Cappuccino cappuccino = new Cappuccino();
System.out.println(cappuccino.getDescription()
+ ": $" + cappuccino.getCost());
}
public void testCafeMocha() {
// This just makes sure it will complete
// without throwing an exception.
// Create a decaf cafe mocha with whipped
// cream
CafeMochaDecafWhipped cafeMocha =
new CafeMochaDecafWhipped();
System.out.println(cafeMocha.getDescription()
+ ": $" + cafeMocha.getCost());
}
public static void main(String[] args) {
CoffeeShop shop = new CoffeeShop();
shop.testCappuccino();
shop.testCafeMocha();
}
} ///:~
And here is the
corresponding output:
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.
The decorator approach
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.
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.
Methods invoked on the Decorator can in
turn invoke methods in the component, and can of course perform processing
before or after the invocation.
So if we added getTotalCost() and
getDescription() methods to the DrinkComponent interface, an
Espresso looks like this:
class Espresso extends Decorator {
private float cost = 0.75f;
private String description = " espresso";
public Espresso(DrinkComponent component) {
super(component);
}
public float getTotalCost() {
return component.getTotalCost() + cost;
}
public String getDescription() {
return component.getDescription() +
description;
}
}
You combine the components to
create a drink as follows, as shown in the code below:
//: cX:decorator:alldecorators:CoffeeShop.java
// Coffee example using decorators
package cX.decorator.alldecorators;
import com.bruceeckel.test.UnitTest;
interface DrinkComponent {
String getDescription();
float getTotalCost();
}
class Mug implements DrinkComponent {
public String getDescription() {
return "mug";
}
public float getTotalCost() {
return 0;
}
}
abstract class Decorator implements DrinkComponent
{
protected DrinkComponent component;
Decorator(DrinkComponent component) {
this.component = component;
}
public float getTotalCost() {
return component.getTotalCost();
}
public abstract String getDescription();
}
class Espresso extends Decorator {
private float cost = 0.75f;
private String description = " espresso";
public Espresso(DrinkComponent component) {
super(component);
}
public float getTotalCost() {
return component.getTotalCost() + cost;
}
public String getDescription() {
return component.getDescription() +
description;
}
}
class Decaf extends Decorator {
private String description = " decaf";
public Decaf(DrinkComponent component) {
super(component);
}
public String getDescription() {
return component.getDescription() +
description;
}
}
class FoamedMilk extends Decorator {
private float cost = 0.25f;
private String description = " foamed milk";
public FoamedMilk(DrinkComponent component) {
super(component);
}
public float getTotalCost() {
return component.getTotalCost() + cost;
}
public String getDescription() {
return component.getDescription() +
description;
}
}
class SteamedMilk extends Decorator {
private float cost = 0.25f;
private String description = " steamed milk";
public SteamedMilk(DrinkComponent component) {
super(component);
}
public float getTotalCost() {
return component.getTotalCost() + cost;
}
public String getDescription() {
return component.getDescription() +
description;
}
}
class Whipped extends Decorator {
private float cost = 0.25f;
private String description = " whipped cream";
public Whipped(DrinkComponent component) {
super(component);
}
public float getTotalCost() {
return component.getTotalCost() + cost;
}
public String getDescription() {
return component.getDescription() +
description;
}
}
class Chocolate extends Decorator {
private float cost = 0.25f;
private String description = " chocolate";
public Chocolate(DrinkComponent component) {
super(component);
}
public float getTotalCost() {
return component.getTotalCost() + cost;
}
public String getDescription() {
return component.getDescription() +
description;
}
}
public class CoffeeShop extends UnitTest {
public void testCappuccino() {
// This just makes sure it will complete
// without throwing an exception.
// Create a plain cappucino
DrinkComponent cappuccino = new Espresso(
new FoamedMilk(new Mug()));
System.out.println(cappuccino.
getDescription().trim() + ": $" +
cappuccino.getTotalCost());
}
public void testCafeMocha() {
// This just makes sure it will complete
// without throwing an exception.
// Create a decaf cafe mocha with whipped
// cream
DrinkComponent cafeMocha = new Espresso(
new SteamedMilk(new Chocolate(new Whipped(
new Decaf(new Mug())))));
System.out.println(cafeMocha.getDescription().
trim() + ": $" + cafeMocha.getTotalCost());
}
public static void main(String[] args) {
CoffeeShop shop = new CoffeeShop();
shop.testCappuccino();
shop.testCafeMocha();
}
} ///:~
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.
If you want to describe a plain
cappuccino, you create it with
new Espresso(new FoamedMilk(new Mug()))
Creating
a decaf Café Mocha with whipped cream requires an even longer
description.
Compromise
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.
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.
Here is how to create a basic selection,
as well as a decorated selection:
//: cX:decorator:compromise:CoffeeShop.java
// Coffee example with a compromise of basic
// combinations and decorators
package cX.decorator.compromise;
import com.bruceeckel.test.UnitTest;
interface DrinkComponent {
float getTotalCost();
String getDescription();
}
class Espresso implements DrinkComponent {
private String description = "Espresso";
private float cost = 0.75f;
public float getTotalCost() {
return cost;
}
public String getDescription() {
return description;
}
}
class EspressoConPanna implements DrinkComponent {
private String description = "EspressoConPare";
private float cost = 1;
public float getTotalCost() {
return cost;
}
public String getDescription() {
return description;
}
}
class Cappuccino implements DrinkComponent {
private float cost = 1;
private String description = "Cappuccino";
public float getTotalCost() {
return cost;
}
public String getDescription() {
return description;
}
}
class CafeLatte implements DrinkComponent {
private float cost = 1;
private String description = "Cafe Late";
public float getTotalCost() {
return cost;
}
public String getDescription() {
return description;
}
}
class CafeMocha implements DrinkComponent {
private float cost = 1.25f;
private String description = "Cafe Mocha";
public float getTotalCost() {
return cost;
}
public String getDescription() {
return description;
}
}
abstract class Decorator implements DrinkComponent {
protected DrinkComponent component;
public Decorator(DrinkComponent component) {
this.component = component;
}
public float getTotalCost() {
return component.getTotalCost();
}
public String getDescription() {
return component.getDescription();
}
}
class ExtraEspresso extends Decorator {
private float cost = 0.75f;
public ExtraEspresso(DrinkComponent component) {
super(component);
}
public String getDescription() {
return component.getDescription() +
" extra espresso";
}
public float getTotalCost() {
return cost + component.getTotalCost();
}
}
class Whipped extends Decorator {
private float cost = 0.50f;
public Whipped(DrinkComponent component) {
super(component);
}
public float getTotalCost() {
return cost + component.getTotalCost();
}
public String getDescription() {
return component.getDescription() +
" whipped cream";
}
}
class Decaf extends Decorator{
public Decaf(DrinkComponent component) {
super(component);
}
public String getDescription() {
return component.getDescription() + " decaf";
}
}
class Dry extends Decorator {
public Dry(DrinkComponent component) {
super(component);
}
public String getDescription() {
return component.getDescription() +
" extra foamed milk";
}
}
class Wet extends Decorator {
public Wet(DrinkComponent component) {
super(component);
}
public String getDescription() {
return component.getDescription() +
" extra steamed milk";
}
}
public class CoffeeShop extends UnitTest {
public void testCappuccino() {
// This just makes sure it will complete
// without throwing an exception.
// Create a plain cappucino
DrinkComponent cappuccino = new Cappuccino();
System.out.println(cappuccino.getDescription()
+ ": $" + cappuccino.getTotalCost());
}
public void testCafeMocha() {
// This just makes sure it will complete
// without throwing an exception.
// Create a decaf cafe mocha with whipped
// cream
DrinkComponent cafeMocha = new Whipped(
new Decaf(new CafeMocha()));
System.out.println(cafeMocha.getDescription()
+ ": $" + cafeMocha.getTotalCost());
}
public static void main(String[] args) {
CoffeeShop shop = new CoffeeShop();
shop.testCappuccino();
shop.testCafeMocha();
}
} ///:~
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.
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.
Other considerations
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.
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.
Exercises
- Add a Syrup class to the
decorator approach described above. Then create a Café Latte (you'll need
to use steamed milk with an espresso) with
syrup.
- Repeat
Exercise 1 for the compromise
approach.
- Implement
the decorator pattern to create a Pizza restaurant, which has a set menu of
choices as well as the option to design your own pizza. Follow the compromise
approach to create a menu consisting of a Margherita, Hawaiian, Regina, and
Vegetarian pizzas, with toppings (decorators) of Garlic, Olives, Spinach,
Avocado, Feta and Pepperdews. Create a Hawaiian pizza, as well as a Margherita
decorated with Spinach, Feta, Pepperdews and
Olives.