Decorator Pattern

Decorator Pattern
Steven R. Bagley

Introduction
• Decorator Pattern
• Inheritance vs. Composition

Tricolour Coffee Bar
• Fast-growing coffee chain
• Started by a computer
scientist
• Wants a fully OO based
ordering system

Drinks
• Coffees
• House Blend
• Dark Roast
• Decaf
• Espresso
• Toppings
• Mocha
• Steamed Milk
• Soy
• Whip

Where to Begin?
• Assume it serves only drinks
• Abstract base class of Drink
• Coffee Types inherit from Drink
• Methods for
• Description
• Cost

Drink
description
GetDescription
Cost
HouseBlend
cost()
DarkRoast
cost()
Decaf
cost()
Espresso
cost()

class CBeverage
{
public:
string GetDescription();
virtual double cost() = 0;
protected:
string m_description;
};
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

class CBeverage
{
public:
string GetDescription();
virtual double cost() = 0;
protected:
string m_description;
};
same as abstract
in Java
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

string CBeverage::GetDescription()
{
return m_description;
}

class CHouseBlend : public CBeverage
{
public:
CHouseBlend();
virtual double cost();
};
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

class CHouseBlend : public CBeverage
{
public:
CHouseBlend();
virtual double cost();
};
provide an
implemenation of the
abstract method
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

CHouseBlend::CHouseBlend()
{
m_description = “House Blend”;
}
double CHouseBlend::cost()
{
return 0.89;
}

Toppings
• What about the Toppings?
• Inherit the various types?
• EspressoWithMocha
• DarkRoastWithSteamedMilk
• Implementation as before

CHouseBlendWithMocha::
CHouseBlendWithMocha()
{
m_description = “House Blend with Mocha”;
}
double CHouseBlendWithMocha::cost()
{
return 0.89 + 0.20;
}

Class Explosion
• Where did all these classes come from?
• 16 combination of toppings
• 4 drinks
• 64 different classes to implement
• Maintenance nightmare!
• What if the cost of Mocha topping goes up?

Design Principles
• Does it break our Design Principles?
• Encapsulate what varies
• Favour composition over inheritance
• Program to interfaces, not
implementation
Always a good idea to measure your design up against these design principles. Try and
justify why you are breaking one... It is almost certainly a bad idea

Encapsulate what varies
• Fail here — Big Time!
• Nothing is encapsulated
• DarkRoastWithMocha
• HouseBlendWithMocha
• HouseBlendWithSteamedMilk
• No Code Reuse…

Favour Composition
• Inheritance 64 — Composition 0
• No composed classes
• Definite fail here…

Interface
• We meet this
• Beverage interface
• No need to use concrete classes

Square One
• Unworkable design
• A new topping means 64 new classes
• A new coffee means 16 new classes
• Back to the drawing board
• Need to do this without using so many
classes

Attempt Two
• Apply first design principle
• Put the toppings into Beverage as instance
variables
• Encapsulates what varies
• Sub-classes call Beverage’s cost() to get
cost of toppings

Drink
description
milk
soy
mocha
whip
GetDescription
Cost
HasMilk
SetMilk
HasSoy
SetSoy
HasMocha
SetMocha
HasWhip
SetWhip
HouseBlend
cost()
DarkRoast
cost()
Decaf
cost()
Espresso
cost()

int CDrink::Cost()
{
int cost = 0;
if(m_hasMocha)
cost += 0.20;
if(m_hasMilk)
cost += 0.10;
…
return cost;
}

int CDarkRoast::Cost()
{
return CDrink::Cost() + 1.50;
}

WooHoo
• Only five classes
• Code reuse
• No Ducks!
• This must be the way to do it!

Or maybe not…
• Price changes to toppings mean we have to
edit existing code (we could break it)
• New toppings mean new methods and
editing the cost method (recompile
everything)
• What about drinks without toppings?
• Or double toppings?

Inheritance
• Inheritance is powerful
• Doesn’t always lead to flexible designs
• Can ‘inherit’ behaviour at runtime via
composition

Inherit or Compose
• Behaviour is fixed statically at compile time
• Composition can extend at runtime
• Composition allows us to add new
responsibilities to objects without touching
the superclass
• New functionality by writing new code, not
editing old (and working) code

Design Principle
“Classes should be open for extension,
but closed for modification”

Open-Closed Principle
• Classes should be open for extension
• Feel free to extend our classes with any
new behaviour you like, but…
• closed for modification
• Sorry, but our code is fixed and bug free
you can’t change it
• Inheritance means code-change

Open-closed Design
• How do you design something to be open
for extension but closed to modification?
• Lots of OO techniques
• Keep things loosely coupled

Tightly coupled
example
• Suppose we have a class that prints stuff
• Outputs the data to the standard output in
the usual way
System.out.println(“…”);
printf(“…”);
• Coupled tightly to the output classes
• Can’t work with out them, can’t output to
anything else

public class TightCouple
{
public DebugOutput()
{
System.out.println(“Debug output”);
…
System.out.println(“End Debug”);
}
}

Make it loosely coupled
• Class is tied to outputting to standard
output
• Via the System.out class
• If we want to output to a file (or
elsewhere) then we’d need to rewrite code
• However, we can rewrite it to be loosely
coupled

public class LooseCouple
{
public DebugOutput(PrintStream output)
{
output.println(“Debug output”);
…
output.println(“End Debug”);
}
}

obj.DebugOutput(System.out);
Call it by passing it a reference or pointer to the object
it uses to print things out
obj no longer tied to any specific output

Decorator Pattern
• ‘We need to sell some coffee here’
• Can use the Decorator Pattern to
solve this design
• Uses composition rather than inheritance

Dark

MochaDark

Whip MochaDark

Whip MochaDark
All Objects are of the
same type, Drink

All Objects are of the
same type, Drink
Whip MochaDark
Mocha and Whip are ‘Decorators’, they
take an object of type Drink and wrap it up

Decorator
• Start with a DarkRoast object
• Customer wants Mocha, wrap a Mocha
object around DarkRoast
• Also want Whip, wrap a Whip object
around Mocha
• Both decorators and concrete classes share
same type, Drink

Coffee Decorators
• How it works
• Call cost() on the decorated object
• Decorator calls cost() on the object it
decorates and adjusts the price
• Decorators can decorate Decorators

Drink
description
GetDescription
Cost
HouseBlend
cost()
DarkRoast
cost()
Decaf
cost()
Espresso
cost()
CondimentDecorator
Drink
Milk
cost
GetDescription
Mocha
cost
GetDescription
Soy
cost
GetDescription
Whip
cost
GetDescription

class CBeverage
{
public:
virtual string GetDescription();
virtual double Cost() = 0;
protected:
string m_description;
};
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

string CBeverage::GetDescription()
{
return m_description;
}

string CBeverage::GetDescription()
{
return m_description;
}
return a copy of
the description

class CHouseBlend : CBeverage
{
public:
CHouseBlend();
virtual double Cost();
};
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

class CHouseBlend : CBeverage
{
public:
CHouseBlend();
virtual double Cost();
};
provide an
implemenation of the
abstract method
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

string CHouseBlend::CHouseBlend()
{
m_description = “House Blend”;
}
double CHouseBlend::Cost()
{
return 0.89;
}

class CCondimentDecorator : public CBeverage
{
public:
virtual string GetDescription() = 0;
virtual double Cost() = 0;
};
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

class CMocha : public CCondimentDecorator
{
public:
! CMocha(CBeverage *beverage);
! ~CMocha();
!
! virtual string GetDescription();
! virtual double Cost();
private:
! CBeverage *m_beverage;
};
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

CMocha::CMocha(CBeverage *beverage)
{
! m_beverage = beverage;
}
CMocha::~CMocha()
{
! delete m_beverage;
}
string CMocha::GetDescription()
{
! return m_beverage->GetDescription() + ", Mocha";
}
double CMocha::Cost()
{
! return m_beverage->Cost() + 0.20;
}
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

! CBeverage *beverage2 = new CDarkRoast();
! beverage2 = new CMocha(beverage2);
! beverage2 = new CMocha(beverage2);
Abstract class -- can’t instantiate directly
but we can instantiate subclasses

Decorator Pattern
• The Decorator Pattern attaches additional
responsibilities to an object dynamically.
Decorators provide a flexible alternative to
subclassing for extending functionality
• Black-box reuse
• Classes implementation unchanged

Decorator
Components
• Abstract Component interface
• Some Concrete Components that implement
interface
• Some Decorators that also implement the
interface

Decorator
• Each Decorator has-a component that it
wraps up (instance variable containing a
reference)
• Decorators add functionality
• New Methods (unusual)
• Additional code before or after existing
methods

Decorated Inheritance
• Inheritance is used to get type
compatibility, not behaviour
• Object being decorated is never changed
• If it is bug-free it stays bug free
• If we inherit, we are effectively altering the
code for that object which can introduce
bugs

Inheritance means
rewrite
• Suppose a class has two methods
• foo()
• bar()
• foo() uses bar() to do some of its work
• Inherit a new class which replaces bar()’s
behaviour
• foo() does not work correctly anymore

Do not modify
• On the other hand if we decorate the class
to replace bar()
• foo() still works (it calls the original bar
())
• New bar() still called via decorator
• Inherit for type, not behaviour

Deja vu
• Anyone getting the impression they’ve seen
this before?

Java File I/O
• Java’s File I/O is based around the
Decorator Pattern
• Abstract root InputStream
• Concrete base types FileInputStream,
StringBufferStream
• Stream Decorators (FilterInputStream)
BufferedInputStream,
LineNumberInputStream

InputStream in = new BufferedInputStream(new
FileInputStream(“test.txt”));
in.read();
Only have to implement bufferedInputStream once, not for every input stream type

public class LowerCaseInputStream extends FilterInputStream
{
! public LowerCaseInputStream(InputStream in)
{
! ! super(in);
! }
! public int read() throws IOException
{
! ! int c = super.read();
! ! return (c == -1 ? c : Character.toLowerCase((char)c));
! }
! !
! public int read(byte[] b, int offset, int len) throws …
{
! ! int result = super.read(b, offset, len);
! ! for (int i = offset; i < offset+result; i++)
{
! ! ! b[i] = (byte)Character.toLowerCase((char)b[i]);
! ! }
! ! return result;
! }
}
Easy to implement new input stream filters