1. LECTURE 18: Design Patterns Command, 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. Command Pattern Motivation
Before:
Method 1
Method 2
Client
Server (Receiver)
Problem: Variable and evolving method signature
If Server code changes, Client code needs to change, too

6. 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:
Method 1
Method 2
Client
Server (Receiver)
execute()
Client
Command 1
Command 2
Method 1
Method 2
Server (Receiver)
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
(b)
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

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. Example: Midterm #2, Spring 2013
Given:
State diagram for Display Interaction:
Ready
Faulty
measurement-initiated /
failure-detected /
Measuring
[battery-level  threshold] /
Discharged
measurement-completed /
battery-charged /
button-pressed / display msg 
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

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

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

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

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

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

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

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
(a)
(b)
Notes:
Proxy is structurally the same as Decorator, but has different intention
We could have a “linked list” of Proxies, like with Decorators
(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)
UC-4: View Access Log ======(this block comes before)====== accessList := retrieve(params : string)