1. PH Chapter 3 Thanks for the Memory Leaks Pushme-Pullyu (pp
PH Chapter 3 Thanks for the Memory Leaks Pushme-Pullyu (pp ) GoF Command Pattern (pp )
By: Dan Sibbernsen
25/06/09

2. Thanks for the Memory Leaks
Overview
Dynamically created cursors, how do we track them for deletion?
Need to avoid leaking memory, responsibility lies within the Client for deletion
Solution
Bridge Pattern (aka Handle-Body)

3. Bridge Introduce a CursorImp class Pg. 100-101 (implementation)
Serves as an abstract Memento class, rather than Cursor
Cursor serves as a Handle to CursorImp, and we increment a reference count inside Handle every time the constructor is called
Pg (implementation)

4. Pushme-Pullyu Problem Pull Push
Having to downcast a type to something application specific
Pull
Consumer, or the application, pulls information from the framework
Push
Consumer waits for the Producer

5. Design Questions Push Or Pull?
Push: Makes it easier to implement Consumer
Pull: Makes it easier to implement Producer

6. Command Pattern Intent Motivation Provides for undoable operations
Able to pass requests as objects, gives added flexibility, such as queuing or logging requests.
Motivation
To decouple issuing requests from both the operation being done and the receiver.

7. Class Diagram

8. Class Responsibilities
Command
Abstract interface for executing operations
ConcreteCommand
Binds the Receiver object to an Action
Client
Instantiates a ConcreteCommand with a Receiver
Invoker
“Tells the command to carry out the request”
Receiver
Can perform the operation defined by the Command

9. Interaction Diagram

10. Consequences (Good) Decouples requester from operation of the class.
Command can be manipulated for the greater good (which, of course, is extensibility)
Can use the composite pattern to treat all commands uniformly
New commands can be added easily

11. Implementation Details
How Intelligent should a command be?
Very simple: merely a binding between receiver and the request’s action
Very ingrained: command implements everything without delegating to any receiver
Defines commands that don’t fit into any existing classes
When no suitable receiver exists
When the command knows its receiver implicitly

12. Implementation Details
Supporting Undo and Redo
Keep a function that can reverse the execution
Possibly need a ConcreteCommand to store state
To support multiple levels, we need to store a list of these commands

13. Implementation Details
Avoiding error accumulation in the undo process
Undo/Redo can change the state of the program, and have errors accumulate that will change the state.
Memento Pattern can be used to store state of the program at the command’s execution to guarantee it is in the original state.
Can be done without exposing class internals

14. Implementation Details
Using C++ Templates
Can be used in cases where actions aren’t undoable, and don’t require arguments
Eliminates need for creating a subclass for every action/receiver pair
(sample code on page 239)

15. Related Patterns
Composite
Memento
Prototype