1 Ivan Marsic Rutgers University LECTURE 18: Design Patterns Command, Decorator, State, Proxy

2 Topics  Command Pattern  Decorator Pattern  State Pattern  Proxy Pattern –Protection Proxy

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

4 Command Pattern Motivation  Motivation: To separate parameter preparation from passing program control (decision on when to call) Client A Client A Server B Server B doAction( params ) Client A Client A execute() Receiver B Receiver B doAction( params ) Command create( params ) unexecute()  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 Parameters may be prepared by a different object (“Custodian”) (Server) PreparationExecution

5 Command Pattern Motivation  Problem: Variable and evolving method signature –If Server code changes, Client code needs to change, too Client Server (Receiver) Before:

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

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 (a) Forward execution (do) (c) (b)

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

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) (c) (b) Uniform method calling, regardless of the head-of-the-list object identity Pre-processing Post-processing Pre- versus Post-processing is defined relative to the essential feature: the request() of RealSubject

14 Decorator Example – GUI Options

15 Decorator - Example

16 Deco Example – Unlock Use Case

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

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

19 Student solution: Class diagram  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 client «interface» DeviceCheck + check() ButtonCheck + increment() Subject and Decorator interface BatteryCheck + checkBattery() DeviceWearChk + checkWearing() nextDevice FaultyCheck + checkSensor() Concrete Decorators MeasuringCheck + chkMeasuring() BP_Check + checkBP() + display() HR_Check + checkBP() + display() AL_Check + checkAL() + display() BL_Check + checkBL() + display() Real Subjects

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

21 display Student sol’n: Sequence diagram  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!! : DeviceWearChk: FaultCheck: Measuring Check checkFault() client : display error msg alt [else] buttonPress( ) device not worn OR faulty OR measuring checkWearing() checkMeasuring() : BPCheck checkBP() : HRCheck checkHR() display

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

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

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 (a) (b) (c)

26 State Pattern (a) (b) (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)