1CMSC 433, Fall 200292Multiple Window Systems•Want portability to different window systems–similar to multiple look-and-feel problem, but different vendors will build widgets differently•Solution:–define abstract class Window, with basic window functionality (e.g., draw, iconify, move, resize, etc.)–define concrete subclasses for specific types of windows (e.g., dialog, application, icon, etc.)–define WindowImphierarchy to handle window implementation by a vendorCMSC 433, Fall 200293Implementation2CMSC 433, Fall 200294Bridge Pattern•Name–Bridge or Handle or Body•Applicability–handles abstract concept with different implementations–implementation may be switched at run-time–implementation changes should not affect clients–hide a class’s interface from clients•Structure: use two hierarchies –logical one for clients, –physical one for different implementationsCMSC 433, Fall 200295Structure of Bridge Pattern3CMSC 433, Fall 200296Bridge Pattern•Consequences:–decouple interface from impl.and representation–change implementation at run-time–improve extensibility•logical classes and physical classes change independently•hides implementation details from clients– sharing implementation objects and associated reference countsCMSC 433, Fall 200297Supporting User Commands•Support execution of Lexicommands–GUI doesn’t know •who command is sent to •command interface•Complications–different commands have different interfaces–same command can be invoked in different ways –Undo and Redo for some, but not all, commands (print)4CMSC 433, Fall 200298Supporting User Commands (cont’d)•An improved solution–create abstract “command” class•command must have reversible method–create action-performing glyph subclass –delegate action to command•Key ideas–pass an object, not a function–pass context to the command function–store command historyCMSC 433, Fall 200299Command Objects5CMSC 433, Fall 2002100Command Pattern•Name–Command or Action or Transaction•Applicability–parameterize objects by actions they perform–specify, queue, and execute requests at different times–support undo by storing context information –support change log for recovery purposes–support high-level operations•macrosCMSC 433, Fall 2002101Structure of Command Pattern6CMSC 433, Fall 2002102Command Pattern•Consequences:–decouple receiver and executor of requests•Lexiexample: Different icons can be associated with the same command–commands are first class objects–easy to support undo and redo •must add state information to avoid hysteresis–can create composite commands•Editor macros–can extend commands more easilyCMSC 433, Fall 2002103Command Pattern•Implementation notes–how much should command do itself?–support undo and redo functionality•operations must be reversible•may need to copy command objects•don’t record commands that don’t change state–avoid error accumulation in undo process7CMSC 433, Fall 2002104Spell-Checking and Hyphenation•Must do textual analysis–multiple operations and implementations•Must add new functions and operations easily•Must efficiently handle scattered information and varied implementations –different traversal strategies for stored information•Should separate actions from traversalCMSC 433, Fall 2002105IteratorPattern•Name–Iteratoror Cursor•Applicability–access aggregate objects without exposing internals–support multiple traversal strategies–uniform interface for traversing different objects8CMSC 433, Fall 2002106IteratorPattern•Key ideas–separate aggregate structures from traversal protocols–support addition of traversal functionality–small interfaces for aggregate classes, –multiple simultaneous traversals•Pattern structure–abstract Iteratorclass defines traversal protocol–concrete Iteratorsubclasses for each aggregate class–aggregate instance creates instances of Iteratorobjects–aggregate instance keeps reference to IteratorobjectCMSC 433, Fall 2002107Structure of IteratorPattern9CMSC 433, Fall 2002108Structure of IteratorPatternCMSC 433, Fall 2002109IteratorPattern (cont’d)• Consequences–support different kinds of traversal strategies•just change Iteratorinstance–simplify aggregate’s interface•no traversal protocols–supports simultaneous traversals10CMSC 433, Fall 2002110IteratorPattern (cont’d)•Implementation issues•Who controls iteration?–external vs. internal iterators•external: –client controls the iteration via “next” operation–very flexible –some operations are simplified -logical equality and set operations are difficult otherwise•internal: –Iteratorapplies operations to aggregate elements–easy to use–can be difficult to implement in some languagesCMSC 433, Fall 2002111IteratorPattern (cont’d)•Who defines the traversal algorithm?–Iteratoritself•may violate encapsulation–aggregate (in a “cursor”)•Iteratorkeeps only state of iteration•How robust is the Iterator?–are updates or deletions handled?–don’t want to copy aggregates–register Iteratorswith aggregate and clean-up as needed–synchronization of multiple Iteratorsis difficultThis document was created with Win2PDF available at http://www.daneprairie.com.The unregistered version of Win2PDF is for evaluation or non-commercial use
View Full Document
Unlocking...