Summary of Thanks for the Memory Leaks Leftover

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 Cursor. Imp (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: Co. R, 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 <<Client>> << >> stereotype gives role name <<Invoker>> * <<Command>> execute ( ) <<Concrete. Command>> <<Receiver>> execute ( ) action(args) state_ 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 a. Client a. Receiver a. Command an. Invoker construct store time / / action / / execute / / 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) Client System action Undo. Command Undo. Stack remember construct store time / / undo / / restore / / execute 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? CSE 432: Thanks for the memory leaks, Pushme-Pullyu, and Command