The Decorator Pattern CSCI 3132 Summer 2011 1 Starbuzz Coffee • Want to offer a variety of combinaons of coffee and condiments • Cost of a cup depends on the combinaon that was ordered 2 First Design • Make a beverage class and a subclass for each legal combinaon <<abstract>> Beverage String description getDescription() <<abstract>> cost() HouseBlend DarkRoast Decaf Espresso cost() cost() cost() cost() HouseBlendWith DecafWith EspressoWit SteamedMilk DarkRoastWith SteamedMilkSteamedMi l cost()HouseBlend SteamedMilk costDecaf() costEspresso() Mocha cost()DarkRoast Mocha Mocha HouseBlendcost() Mocha Decafcost () Espressocost() WithWhip DarkRoastcost() WithWhip WithWhip WithWhip cost() 3 cost() cost() 3 Problems with Inheritance • Too many subclasses may be needed. • Need to define the implementaon of each subclass. • All classes inherit a stac behaviour which may have to be overridden. • The inherited behaviour cannot be changed at run5me, i.e. behaviour is stac at run5me. • Thus, the design is not flexible or maintainable. 4 Second Design • Make the superclass contain booleans to specify which condiments are included and subclasses for each type of coffee • How do we compute cost? • What does it take to add a new condiment? 5 <<abstract>> Beverage String description milk soy mocha whip getDescription() <<abstract>>cost () hasMilk() setMilk() hasSoy() setSoy() Decaf hasMocha() HouseBlend setMocha() cost() cost() hasWhip() setWhip() … DarkRoast Espresso cost() cost() 6 Design Principle • Classes should be open for extension, but closed for modificaon – “extension” is NOT subclassing – It means the addi5on of new behavior (without modifying the code!) 7 Decorator Paern • Start with an instance of the “basic”classes and then decorate it with new capabili5es Whip Mocha Dark Roast cost() cost() cost() 0.99 0.99+0.20 0.99+0.20+0.10 8 Key Points • Decorators have the same supertypes as the objects they decorate – This lets us pass around the decorated object instead of the original (unwrapped) object • Decorator add behavior by delegang to the object it decorates and then adding its own behavior • Can add decoraons at any 5me 9 Class Diagram for the Decorator Paern 10 Starbuzz Coffee Example 11 public abstract class Beverage{! String description = “Unknown”;! public String getDescription() {! return description;! }! public abstract double cost();! }! public abstract class CondimentDecorator extends Beverage {! public abstract String getDescription();! public abstract double cost();! }! public class Espresso extends Beverage {! public Espresso() {! description = “Espresso”; ! }! public double cost() {! return 1.99;! }! }! 12 public class Mocha extends CondimentDecorator {! Beverage bev;! public Mocha(Beverage bev) {! this.bev = bev;! }! public String getDescription {! return bev.getDescription() + “, Mocha”;! }! public double cost() {! return .20 + bev.cost();! }! }! 13 public class StarBuzz {! public static void main(String args[]) {! Beverage bev = new Espresso); ! bev = new Mocha(bev);! bev = new Mocha(bev);! bev = new Whip(bev);! bev = new Soy(bev);! System.out.println(bev.getDescription() + “ $”+! bev.getCost()); ! }! 14 Decorators in Java • File I/O Example Concrete decorators Component BufferedInputStream LineNumberInputStream FileInputStream 15 Design Principle for the Decorator Paern • Classes should be open for extension but closed for modificaon. • Systems can be extended without changing exis5ng code. • Tradeoffs: – Takes 5me and effort. – Introduces new levels of abstrac5on which makes designs more complicated and code hard to understand. • Due to the tradeoffs the decorator paern should not be used throughout the design but in areas that are most likely to change. • Experience and looking at other examples helps one determine which areas are likely to change. 16 Decorator Paern • Provides a flexible alternave to using inheritance to extend func5onality. • This achieved by introducing decorators that “decorate” objects. • Decorators have the same type as the objects they decorate. • An object can have one or more decorators. 17 The Decorator Paern • The decorated object and the original object have the same type. Thus, the decorated object can be passed instead of the original object. • The decorator delegates part of its behaviour to the object it decorates. • It adds its own behaviour before or aer the delegaon. • Objects can be delegated dynamically at run5me. • The objects are “wrapped” with decorators. 18 Decorator Paern Summary • Main design principle: Classes should be open for extension but closed for modificaon. • Achieves flexibility- behaviour can be extended without changing exis5ng code. • Composi5on and delegaon is used to add new behaviours at run5me. • A set of decorator classes are used to wrap concrete components. • Overuse of decorators can be complex as they can introduce a number of small objects into a design. 19 .