CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command Summary of “Thanks for the Memory Leaks” “Left-over” design forces from Type Laundering –Need to avoid leaking dynamically created cursors –Cannot predict when clients will obtain/release them Solution: handle-body idiom (similar to Bridge) –Body role is played by CursorImp (implementation) Performs reference counting in the ref/unref methods This is another idiom: “last one out turn off the lights” –Handle role is played by Cursor (interface) Call ref/unref reference counting methods correctly User can copy, destroy, etc. handles at will Important details matter like return-by-value in cursor()

CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command Summary of “Pushme-Pullyu” Pull (client calls) vs. push (client called) events –Active vs. passive, blocking vs. callback, etc. –Important question: “locus of control” Push simplifies consumer, increases producer complexity Pull simplifies producer, increases consumer complexity Design forces –Different events have disjoint interfaces –Want to deliver events in a type safe way –Let applications define new events transparently Solution –Handlers register for events, can be combined as “mix ins” –Handlers provide event-type-specific handle methods Similarities to: CoR, Mediator, Multicast (on Wed) Common in publish/subscribe, event channel systems

CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command Review of Command Pattern (from 1 st Lecture) Problem –Want to issue requests to objects –Don’t know in advance which request(s) will be made –Don’t know in advance to what object(s) they will go Solution core –Encapsulate function call parameters and target object reference inside an “execute” method (or operator() ) Consequences –Decouples invocation/execution –Commands are first-class objects (elevates functions) –Easy to compose, add new ones Examples of know uses –STL function objects, items in undo stacks,

CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command Command Structure Diagram Command role encapsulates a function as an object Invoker calls command, command calls receiver –Same class may play one or several of these roles > action(args) execute ( ) state_ * > stereotype gives role name

CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command Command Interaction Diagram Client creates command, gives to invoker Invoker executes command when appropriate –Command then invokes action on the receiver aCommandanInvokeraClientaReceiver / construct store executeaction time

CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command Example Use of Command: Undo Client performs action, undo stack remembers Undo call executes top command on stack Command restores previous state (LIFO) UndoCommandUndoStackClientSystem / construct store executerestore time action remember undo

CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command A Couple Variations on the Undo Example Some actions have closed form inverses –Object creation/destruction, some arithmetic, etc. –Natural to implement undo as in previous slide –Simply store command for inverse action in stack Some actions do not have closed form inverses –Randomization (shuffling), arbitrary state changes –Further constrains the space of possible designs –New design force: offer undo commands without requiring an action have an inverse action –Solution: use memento to remember prior state –Why not implement undo this way always?