By: Dan Sibbernsen 25/06/09

1. PH Chapter 3 Thanks for the Memory LeaksPushme-Pullyu (pp. 110-121)GoF Command Pattern (pp. 233-242) 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 • 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. 100-101 (implementation)

4. Pushme-Pullyu • Problem • 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 • 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