The Decorator Pattern

CSCI 3132 Summer 2011 1

Starbuzz  Coffee  

• Want  to  offer  a  variety  of  combina5ons  of  coffee  and  condiments  

•  Cost  of  a  cup  depends  on  the  combina5on  that  was  ordered  

2

First  Design  

• Make  a  beverage  class  and  a  subclass  for  each  legal  combina5on  

3

HouseBlend cost()

DarkRoast cost()

Decaf cost()

Espresso cost()

HouseBlendWith SteamedMilk cost()

DarkRoastWith SteamedMilk cost()

DecafWith SteamedMilk cost()

EspressoWitSteamedMilcost() HouseBlend

Mocha cost()

DarkRoast Mocha cost()

Decaf Mocha cost()

Espresso Mocha cost() HouseBlend

WithWhip cost()

DarkRoast WithWhip

Decaf WithWhip cost()

Espresso WithWhip cost()

Beverage String description getDescription() <<abstract>> cost() �…

<<abstract>>

3

Problems  with  Inheritance  

•  Too  many  subclasses  may  be  needed.  •  Need  to  define  the  implementa5on  of  each  subclass.  

•  All  classes  inherit  a  sta5c  behaviour  which  may  have  to  be  overridden.  

•  The  inherited  behaviour  cannot  be  changed  at  run5me,  i.e.  behaviour  is  sta5c  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

Beverage String description milk soy mocha whip getDescription() <<abstract>>cost() hasMilk() setMilk() hasSoy() setSoy() hasMocha() setMocha() hasWhip() setWhip() …

HouseBlend cost()

DarkRoast cost()

Decaf cost()

Espresso cost()

<<abstract>>

6

Design  Principle  

•  Classes  should  be  open  for  extension,  but  closed  for  modifica5on  – “extension”  is  NOT  subclassing  – It  means  the  addi5on  of  new  behavior  (without  modifying  the  code!)  

7

Decorator  PaSern  

•  Start  with  an  instance  of  the  “basic”classes  and  then  decorate  it  with  new  capabili5es  

Dark Roast

Mocha

cost() cost()

Whip

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  delega5ng  to  the  object  it  decorates  and  then  adding  its  own  behavior  

•  Can  add  decora5ons  at  any  5me  

9

Class  Diagram  for  the  Decorator  PaSern    

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  

FileInputStream

BufferedInputStream LineNumberInputStream

Component

Concrete decorators

15

Design  Principle  for  the  Decorator  PaSern  

•  Classes  should  be  open  for  extension  but  closed  for  modifica5on.  

•  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  paSern  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  PaSern  

•  Provides  a  flexible  alterna5ve  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  PaSern    

•  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  aZer  the  delega5on.  

•  Objects  can  be  delegated  dynamically  at  run5me.  

•  The  objects  are  “wrapped”  with  decorators.  18

Decorator  PaSern  Summary  

•  Main  design  principle:  Classes  should  be  open  for  extension  but  closed  for  modifica5on.  

•  Achieves  flexibility-­‐  behaviour  can  be  extended  without  changing  exis5ng  code.  

•  Composi5on  and  delega5on  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