Decorator Pattern. Steven R. Bagley

Transcription

1 Decorator Pattern Steven R. Bagley

2 Introduction Decorator Pattern Inheritance vs. Composition

3

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

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

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

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

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

9 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

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

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

12 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

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

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

15 CHouseBlendWithMocha:: CHouseBlendWithMocha() { m_description = House Blend with Mocha ; } double CHouseBlendWithMocha::cost() { return ; }

16

17 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?

18 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

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

20 Favour Composition Inheritance 64 Composition 0 No composed classes Definite fail here

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

22 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

23 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

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

25 int CDrink::Cost() { int cost = 0; if(m_hasmocha) cost += 0.20; if(m_hasmilk) cost += 0.10; return cost; }

26 int CDarkRoast::Cost() { return CDrink::Cost() ; }

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

28 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?

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

30 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

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

32 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

33 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

34 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

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

36 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

37 public class LooseCouple { public DebugOutput(PrintStream output) { output.println( Debug output ); output.println( End Debug ); } }

38 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

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

40

41 Dark

42 MochaDark

43 Whip MochaDark

44 Whip MochaDark All Objects are of the same type, Drink

45 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

46 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

47 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

48 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

49 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

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

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

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

53 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

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

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

56 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

57 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() ; } Abstract class -- can t instantiate directly but we can instantiate subclasses

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

59 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

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

61 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

62 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

63 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

64 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

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

66 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

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

68 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