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

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)

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. 100-101 (implementation)

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

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

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.

Class Diagram

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

Interaction Diagram

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

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

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

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

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)

Related Patterns Composite Memento Prototype