Design Patterns. Decorator. Oliver Haase

Transcription

1 Design Patterns Decorator Oliver Haase 1

2 Motivation Your task is to program a coffee machine. The machine brews plain coffee, coffee with cream, sugar, sweetener, and cinnamon. A plain coffee costs 0,90, cream costs 0,20, sugar 0,10, sweetener 0,10, cinnamon 0,05. A plain coffee has zero calories, a portion of cream adds 10 calories, a portion of sugar 20 calories, both sweetener and cinnamon don't add any calories. All extras can be combined with each other. Model the coffee entity (entities) such that it can be asked for its configuration, its price, and its calories. 2

3 Option 1 - Class Explosion 3 Coffee CoffeeWith Cream CoffeeWith Sugar CoffeeWith Sweetener CoffeeWith Cinammon CoffeeWith CreamAnd Sugar CoffeeWith CreamAnd Sweetener CoffeeWith CreamAnd Cinammon CoffeeWith SugarAnd Cinammon CoffeeWith SweetenerAnd Cinammon CoffeeWith SugarAnd Sweetener CoffeeWith CreamAnd SugarAnd Sweetener CoffeeWith CreamAnd SugarAnd Cinammon CoffeeWith CreamAnd SweetenerAnd Cinammon CoffeeWith CreamAnd SugarAnd SweetenerAnd Cinammon

4 Option 1 - Class Explosion What if extras can be added more than once (e.g. double cream, double sugar)? Option 1 becomes not only messy, but impossible! 4

5 Option 2 - Attributed Coffee Coffee cream: int sugar: int sweetener: int cinammon: int getprice() getcalories() tostring() cream * sugar * sweetener * cinammon * 0.05 cream * 10 + sugar * 20 String result = "coffee" for ( int i = 0; i < cream; i++) result += " cream";... 5

6 Option 2 - Attributed Coffee What if new extra is to be offered, e.g. sprinkles for 0,30 and 5 calories? Class Coffee needs to be modified. 6

7 Option 3 - Decorated Coffee Coffee getprice() getcalories() tostring() PlainCoffee getprice() getcalories() tostring() "Coffee" CoffeeDecorator component getprice() getcalories() tostring() component.getprice() component.getcalories() component.tostring() CreamDecorator getprice() getcalories() tostring() SugarDecorator getprice() getcalories() tostring() SweetenerDecorator getprice() getcalories() tostring() CinammonDecorator getprice() getcalories() tostring() super.getprice() super.getcalories() + 10 super.tostring() + "Cream" 7

8 Option 3 - Decorated Coffee Sample coffee instantiation: Coffee cupofcoffee = new SugarDecorator( new CreamDecorator( new CreamDecorator( new PlainCoffee()))); Resulting object diagram: cupofcoffee: SugarDecorator component :CreamDecorator component :CreamDecorator component : PlainCoffee 8

9 Option 3 - Decorated Coffee Sample sequence diagram for a getprice call: cupofcoffee: SugarDecorator :CreamDecorator :CreamDecorator : PlainCoffee getprice() getprice() getprice() getprice()

10 Decorator - Structure interface through which clients access (decorated) component Client ConreteComponent operation() plain component that can be decorated Component operation() Decorator component operation() maintains reference to decorated component defines same interface as Component delegates operation calls to decorated component component.operation() ConcreteDecoratorA operation() ConcreteDecoratorB operation() adds its own functionality to decorated component super.operation() own additional functionality 10

11 Pros & Cons Pros Simple, non-intrusive introduction of new decorators objects can be (re-)decorated at runtime in contrast to option 1: class explosion different functionality for different object variants through polymorphism and chaining rather than conditional statements (option 2: object with attributes) object can be decorated with same decorator multiple times 11

12 Pros & Cons Cons multiply decorated object represented by multiple runtime objects runtime penalty, higher complexity, e.g., w.r.t. debugging component and its decorator are not the same object object identity gets lost 12

13 Application Concurrency 1: Assume a non-threadsafe implementation of a mutable pair: public interface MutablePair<E1, E2> { } E1 getleft(); E2 getright(); void setleft(e1 left); void setright(e2 right); void update(e1 left, E2 public class NotThreadSafePair<E1, E2> implements MutablePair<E1, E2> { private E1 left; private E2 right; public NotThreadSafePair(E1 left, E2 right) { this.left = left; } this.right = right; 13

14 public E1 getleft() { return left; public E2 getright() { return right; public void setleft(e1 left) { this.left = left; public void setright(e2 right) { this.right = right; public void update(e1 left, E2 right) { } this.left = left; this.right = right; public String tostring() { return "NotThreadSafePair(" + left + ", " + right + ")"; } 14

15 Application Encapsulate not-threadsafe object with a threadsafe public class ThreadSafePair<E1, E2> implements MutablePair<E1, E2> { private MutablePair<E1, E2> delegate; public ThreadSafePair(E1 left, E2 right) { } delegate = new NotThreadSafePair(left, public synchronized E1 getleft() { } return public synchronized E2 getright() { } return delegate.getright(); 15

16 public synchronized void setleft(e1 left) { } public synchronized void setright(e2 right) { } public synchronized void update(e1 left, E2 right) { delegate.update(left, right): public synchronized String tostring() { return "ThreadSafePair(" + left + ", " + right + ")"; } Object confinement thru Java monitor pattern see: Collections.synchronizedCollection(), Collections.synchronizedList(), etc. 16

17 Application Concurrency 2: Read-only decorators for collections Collections.unmodifiable[Set Map Collection]: static factory methods that wrap backing collection read operations are passed to backing collection modifying operations return UnsupportedOperationException 17

18 Related Patterns Adapter: An adapter modifies the adapted object's interface; a decorator adds functionality to an object without extending its interface. 18

19 Related Patterns Proxy vs Decorator: Client Subject operation() Client Component operation() ConreteComponent operation() Decorator component operation() component.operation() Proxy delegate operation() RealSubject operation() ConcreteDecoratorA operation() ConcreteDecoratorB operation() delegate.operation() super.operation() own additional functionality 19

20 Related Patterns Proxy vs Decorator: Similar structure: both involve a wrapper object that references the real subject But: there is only one proxy, as opposed to many decorators for a single object Different purpose: proxy controls access to subject, while decorator changes component's functionality 20

21 Flyweight 21

22 Motivation Imagine a text processor that represents text documents consisting of pages, rows, words, and characters. For homogeneity, it would be nice to treat the concepts of pages, rows, words, and characters similarly, in particular as objects. Problem: A book with 300 pages can easily contain characters huge overhead if modeled as objects! 22

23 Idea Divide object state into intrinsic and extrinsic state, such that there is only a small number of distinct objects with different intrinsic states. Share these flyweight objects. Feed flyweight objects with extrinsic state for operation invocations. 23

24 Example Character Flyweight Objects intrinsic state: extrinsic state: character code (e.g. Unicode) font, text style (bold, italics, regular), position 24

25 Applicability Use the flyweight pattern only if all of the following apply: An application uses a large number of objects. The memory consumption forbids instantiation of individual objects. A big part of the object state can be moved into the context (can be made extrinsic). Removal of the extrinsic state results in a small number of distinct objects. The application does not depend on the object identity. 25

26 Structure creates and maintains flyweight objects declares operations that get fed with the extrinsic state some implementations of Flyweight might not be shared - these may contain complete state implements the flyweight interface keeps intrinsic state of the shared object has reference to flyweight objects keeps or computes objects extrinsic state 26

27 Interactions Intrinsic and extrinsic state must be clearly distinguishable. Flyweight objects store intrinsic state, clients store or compute extrinsic state and supply it into flyweights' operations. Clients don't create flyweight objects directly. A flyweight factory makes sure flyweight objects are correctly shared. 27

28 Consequences Reduced memory consumption comes at the cost of increased runtime, because client has to compute or access stored extrinsic state information, and pass it into flyweight objects. Memory saving depends on degree of reduction of objects; size of intrinsic state; whether extrinsic state is stored or calculated. 28

29 Extrinsic State Applicability depends on how easily extrinsic state information can be identified and pulled out. Benefit (in terms of memory consumption) depends on whether the amount of extrinsic state for all flyweight objects is less than the original state information. This is the case, if extrinsic state can be computed; is equal for groups of objects. Example character flyweight objects: intrinsic state: Character code (e.g. Unicode) extrinsic state: font, text style, position Client doesn't have to store font and text style per flyweight object, but stores these attributes per bigger chunks of text. 29

30 Related Patterns Flyweight often combined with Composite pattern, to build hierarchy of objects with shared (flyweight) leaves. State and Strategy objects are preferably implemented as flyweight objects. 30

31 Closing Remarks Usually, patterns are intended to keep design simply, to reduce dependencies, to reduce number of classes, etc. simplicity, clarity, maintainability, & friends sometimes - though not always - at the expense of reduced efficiency In contrast, flyweight pattern motivated by efficiency considerations relevance can be expected to decrease as main memory continuously gets cheaper 31

32 Composite 32

33 Motivation Imagine a GUI class library that consists of graphical elements, such as buttons, labels, textboxes, etc. These graphical elements can be grouped and structured in graphical containers. A particular GUI might consist of deeply nested graphical containers and elements. For practical purposes it would, however, be comfortable to be able to treat all graphical components, i.e. containers and elements, the same. E.g. both containers and elements should be able to be asked to paint or scale themselves. 33

34 Idea Define a common supertype GraphicalComponent for both graphical containers and graphical elements; this supertype defines operations on the elements (paint, scale); 34

35 Structure - Example Client GraphicalComponent paint() scale() Textbox paint() scale() Button paint() scale() Label paint() scale() Container components paint() scale() add(graphcomp) remove(graphcomp) getchild(int) for each comp in components comp.paint() for each comp in components comp.scale() 35

36 Sample Run-Time Object Graph :Container components :Container components : Label : Textbox : Label : Button 36

37 General Structure manipulates objects of composite structure thru component interface declares interface for all objects of the nested structure might provide default implementation might define and optionally implement an operation to access an object's parent Client Component operation() defines behavior of complex objects that can contain children stores references to children defines child management operations Leaf operation() represents and defines behavior of primitive objects Composite children operation() add(component) remove(component) getchild(int) for each child in children child.operation() 37

38 Run-Time Object Graph, 2nd :Composite children :Composite children : Leaf : Leaf : Leaf : Leaf 38

39 Applicability Use the composite pattern if you want to model a whole-part-relationship; be able to treat aggregate and atomic objects the same. 39

40 Interactions Clients use the Component interface to interact with objects in the structure. If the target is a primitive object, an operation call is handled directly. If it is a composite, then the composite delegates the call to its children. It might do some extra work before or after the delegation. 40

41 Consequences Composite patterns simplifies clients because they don't need to distinguish between primitive and complex objects New composite and leaf types can be added easily without modifications of the client code Might be too general, if certain composite types should only contain certain leave types leads to explicit type checks at run-time. 41

42 Child Management Operations Two basic options as to where to define operations to manage child objects (add, remove, getchild): 1.In Composite class, as seen more type safety, i.e. client cannot try to add or remove children to primitive object less transparency, i.e. client needs to distinguish between primitive and composite objects when executing childrenrelated operations 2.In Component class, as described by GoF possible default implementation: noop, exception complete transparency, i.e. client can treat primitive and composite objects the same 42

43 Alternative General Structure Client Component operation() add(component) remove(component) getchild(int) Leaf operation() Composite children operation() add(component) remove(component) getchild(int) for each child in children child.operation() 43

44 Reference to Parent Object Operation to access an object's parent can simplify traversal of the composite structure. Where to be modeled? Component How to make sure all children of an object have that object as parent? set children's parent reference only in add and remove operations of class Composite. 44

45 Related Patterns Chain of Responsibility: Reference to parent object often used to implement a chain of responsibility. Flyweight can be used to share components. In that case, references to parent objects don't make sense. Iterator can be used to access all components of a composite structure one by one. Visitor can be used to traverse the structure and perform operations on individual elements. 45

46 Related Patterns Decorator: can technically be regarded degenerated Composite with a decorator containing only one object, and a Composite containing many objects. different purpose: Decorator adds functionality to same logical object, Composite models whole-part-relationship. 46

47 Facade 47

48 Purpose Provides a homogeneous interface to a set of interfaces of a subsystem. Simplifies usability of the subsystem. 48

49 Motivation 49

50 Motivation 50

51 Motivation Problem: Client has to know a lot of classes / interfaces to simply watch a movie many dependencies, tight coupling, hard to change home theater configuration without the need to change all clients 51

52 Motivation 52

53 Description Applicability: Use the facade pattern to hide a subsystem's internal complexity and provide a simplified interface to clients. Systems tend to grow over time, design patterns tend to increase the number of classes. A facade shields clients from that complexity. loosen coupling between the subsystem and clients. A facade removes dependencies from the actual subsystem classes. build multi-layered architectures, separated through one facade per layer as the entry point for the next higher layer. 53

54 Structure knows which subsystem classes are responsible for which requests delegates client requests to respective subsystem objects implements subsystem functionality executes requests from the facade doesn t know facade (doesn t have reference to facade) strict layering 54

55 Interactions Clients use the subsystem by sending requests to the facade. The facade forwards the request to the responsible subsystem objects(s). One client request might well lead to several subsystem requests. Even though the subsystem functionality is implemented in the subsystem, the facade might fill in some logic to orchestrate the lower level requests. Clients that use the facade don't have to use the subsystem directly. 55

56 Comparison of the Structural Patterns 56

57 Circle of Structural Patterns 57

58 Circle of Structural Patterns 58

59 Adapter vs. Bridge Commonalities: Level of indirection for the access to the actual object Delegation from an interface that the actual object doesn't provide 59

60 Adapter vs. Bridge Differences: Purpose: Adapter intends to match an implementation with a (different) interface Bridge intends to separate implementation from abstract to enable both to evolve separately Time of application: Adapter is employed rather later, i.e. when two existing types need to be brought together Bridge is employed early, to foresee separate evolution of abstraction and implementation 60

61 Composite vs. Decorator Commonalities: Structures of composite and decorator very similar (both use recursion to structure hierarchies of objects) Decorator structure might be mistaken for degenerated composite structure composite builds tree, decorator builds chain of objects 61

62 Composite vs. Decorator Differences are in their purpose: Decorator intends to add functionality to a type without changing it avoids exponential explosion of number of classes Composite intents to treat leaves and inner nodes (container objects) of an object hierarchy homogeneously 62

63 Proxy vs. Decorator Commonalities: Similar structures, in both cases indirect access to actual object via upstream object in both cases, upstream object maintains reference to actual object (subject) and delegates requests to it 63

64 Proxy vs. Decorator Differences are in their purpose: Proxy is not about adding functionality, but about avoiding direct access to the subject, for varying reasons (protection, efficiency, transparent remote access) With proxy pattern, subject implements key functionality, with decorator pattern, functionality is split across levels of indirection. 64