Design Patterns Lecture: Command, Decorator, State, Proxy Overview

1. LECTURE 18: Design PatternsCommand, Decorator, State, Proxy Ivan Marsic Rutgers University

2. Topics • Command Pattern • Decorator Pattern • State Pattern • Proxy Pattern • Protection Proxy

3. Command Pattern Motivation create( params ) doAction( params ) doAction( params ) execute() Client A Server B Client A Command Receiver B unexecute() (Server) (a) (b)

4. Command Pattern Motivation • Motivation: To separate parameter preparation from passing program control (decision on when to call) Parameters may be prepared by a different object (“Custodian”) create( params ) doAction( params ) doAction( params ) execute() Client A Server B Client A Command Receiver B unexecute() (Server) • Reasons for separation: • Separate preparation of calling parameters (which may become available much before the execution time or may become available incrementally) • All calling parameters become localized in a Command object (“encapsulated”) • Parameters may be prepared for the Client by a different object (“Custodian”) • Client and Custodian objects’ codes may evolve separately • I.e., different developers develop and maintain or upgrade these classes • May prepare all Commands in a list (with different parameters or different Receivers) and simply iterate through the list to execute all • For un-execute (roll-back) capability Preparation Execution

5. Client Method 1 Method 2 Server (Receiver) Command Pattern Motivation • Problem:Variable and evolving method signature • If Server code changes, Client code needs to change, too Before:

6. Client Method 1 Method 2 Method 2 Method 1 Server (Receiver) Command 1 execute() Client execute() Server (Receiver) Command 2 Command Pattern Improvement The change towards the Cmd. pattern may not appear radical when viewed overall, but looking from the client’s standpoint, the simplification is significant. Before: After:  The interface to the Server object is much simpler.

7. Command Pattern Improvement • Command provides a uniform method signature (“interface”) to the Server • The Command interface never changes, so Server changes do not force Client changes • Client only decides when to execute() • Client evolution is decoupled from Server implementation and Command implementation • Client versus Server/Command can be responsibilities of different developers

8. Command Pattern (b) (a) (c) Forward execution (do)

9. Command Advantages • Execution is usually called with other business logic • Now it is decoupled from parameter preparation, which can be done at another place (“staging area”), not interfering with business logic (“execution area”) • Business logic is decoupled from parameter preparation • Client and Custodian codes may evolve independently, by different developers • NOTE: • The Command method execute() does not return a result • Through a Command, the client gives an order and does not expect to be answered back • If the result of a command execution is needed,it should be retrieved separately, after execute() returns

10. Command Pattern Interaction • Many times commands can be reversed/undone • Extended interface to check for reversibility and, if true, undo (a) (b) Reverse execution (undo)

11. Decorator Pattern Motivation • Motivation: To separate essential from non-essential functions and allow easy adding of new non-essential functions • Implies only one Subject — one essential function, one “responsibility” • Solution: Client only has a pointer to the “head of the list” (of services) and does not know the true identity of the head object • All services in the list look the same since all implement the same interface (here, “list” is not a list data structure!!) • Advantages: • When a new optional function/service is added, client code does not need to change • Only need to program the new function/service and insert it in the “linked list” ( “dependency injection”)

12. Decorator • Client only knows the head-of-the-list • But doesn’t know it’s identity (RealSubject vs. Decorator), because all list elements implement the same abstract interface (Subject) • Client doesn’t know how many Decorators are in the list The list can seamlessly expand or shrink (a) (b)

13. Decorator (a) (b) Pre-processing Uniform method calling, regardless of the head-of-the-list object identity (c) Pre- versus Post-processing is defined relative to the essential feature: the request() of RealSubject Post-processing

14. Decorator Example – GUI Options

15. Decorator - Example

16. Deco Example – Unlock Use Case

17. State diagram for Display Interaction: button-pressed / display msg  Not-Worn wearing-detected / measurement-initiated / Ready Measuring measurement-completed / button-pressed / display msg  button-pressed / display msg  battery-charged / failure-detected / [battery-level  threshold] / Faulty Discharged [battery-level  threshold] / button-pressed / display msg  button-pressed / display msg  Example: Midterm #2, Spring 2013 Given: Problem: Design the UML sequence diagram; apply design patterns

18. client ButtonCheck + increment() FaultyCheck + checkSensor() BatteryCheck + checkBattery() DeviceWearChk + checkWearing() MeasuringCheck + chkMeasuring() BP_Check + checkBP() + display() HR_Check + checkBP() + display() AL_Check + checkAL() + display() BL_Check + checkBL() + display() Concrete Decorators Real Subjects Student solution: Class diagram Subject and Decorator interface «interface» DeviceCheck + check() BP = blood pressure HR = heart rate AL = activity level BL = battery level

19. client ButtonCheck + increment() FaultyCheck + checkSensor() BatteryCheck + checkBattery() DeviceWearChk + checkWearing() MeasuringCheck + chkMeasuring() BL_Check + checkBL() + display() BP_Check + checkBP() + display() AL_Check + checkAL() + display() HR_Check + checkBP() + display() Real Subjects Concrete Decorators Student solution: Class diagram Subject and Decorator interface «interface» DeviceCheck + check() • What went wrong? • Decorators and Subjects don’t implement the top-level interface • Methods are named differently • More than 1 Subject • Not in the spirit of this pattern nextDevice

20. display Student sol’n: Sequence diagram client : : DeviceWearChk : FaultCheck : Measuring Check : BPCheck : HRCheck buttonPress( ) checkWearing() checkFault() checkMeasuring() device not worn OR faulty OR measuring alt display error msg [else] checkBP() display checkHR()

21. display Student sol’n: Sequence diagram client : : DeviceWearChk : FaultCheck : Measuring Check : BPCheck : HRCheck • What went wrong? • Decorator objects are not forming a “linked list” and calling each other uniformly — instead, the Client is calling all decorators in sequence!! buttonPress( ) checkWearing() checkFault() checkMeasuring() device not worn OR faulty OR measuring alt display error msg [else] checkBP() display checkHR()

22. client Decorator + request() Measurement + request() Another Student Solution • Correct use of the Decorator pattern:All Decorators implement the same interface «interface» Subject + request() next object SafetyZoneChecker + request() ActivityLevelChecker + request()

23. Another Student Solution • Uniform calling approach —client calls only the head of the “linked list” client : : SafetyZoneChecker : ActivityLevelChecker : Measurement request( args ) request( args ) request( args ) result  and ‡ denote added special- case processing result checkActivityLevel( ) result‡ checkSafetyZones( )

24. State Pattern Motivation • Motivation: To separate state-dependent event-handling functions from each other and allow easy adding of new states and events • Solution: Event-handling object (“server” or “context”) externalizes its state-dependent functionality into different “state objects” • Context only has a reference to the current state object and does not know its true identity (knows that it’s a state, but not which one) • All State objects look the same (all implement the same interface) • Advantages: • When a new state or event is added, client code does not need to change • Instead of implementing a single big state-transition table, say 10 states by 15 events, we implement 10 State objects • Each State object maintains only a small part of the big table relevant to it(input-event / next-state) • Only need to program the new State object and link it with other states according to the transition diagram ( “dependency injection”)

25. State Pattern (b) (a) (c)

26. State Pattern (b) (a) (c) (d)

27. State Pattern • All State objects are instantiated and mutually interlinked with each other (“dependency injection”) • A State object knows the next states (depending on input events and guard conditions) • State’s method handle(Event) returns the next state • The Context object knows only about one State object (representing the “current state”) and keeps updating it as told by the return value from currentState.handle(Event) . • Context does not know (nor need to know!) the true identity of the current state object – all State objects implement the same abstract interface

28. Proxy Notes: • Proxy is structurally the same as Decorator, but has different intention • We could have a “linked list” of Proxies, like with Decorators (a) (b) (c)

29. Protection Proxy – Example (1) • What if we wanted to add a Maintenance role & access privileges? • Instead of hard-coding the new role privileges,we just define a new Protection Proxy

30. Protection Proxy – Example (2)

31. Protection Proxy – Example (3)