162CMSC 433 – Programming LanguageTechnologies and ParadigmsSpring 2004Design PatternsMarch 4, 2004163Multiple Window Systems• Want portability to different window systems– Similar to multiple look-and-feel problem, but differentvendors will build widgets differently• Solution:– Define abstract class Window, with basic windowfunctionality (e.g., draw, iconify, move, resize, etc.)– Define concrete subclasses for specific types ofwindows (e.g., dialog, application, icon, etc.)– Define WindowImp hierarchy to handle windowimplementation by a vendor164Implementation165Bridge 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 implementations166Structure of Bridge Pattern167Bridge Pattern• Consequences:– Decouple interface from implementation andrepresentation– 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 counts168Supporting User Commands• Support execution of Lexi commands– 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)169Supporting User Commands (cont’d)• An improved solution– Create abstract “command” class– 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 history170Command Objects171Command 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• Macros172Structure of Command Pattern173Command Pattern• Consequences:– Decouple receiver and executor of requests• Lexi example: Different icons can be associated with the samecommand– Commands are first class objects– Easy to support undo and redo• Command must have method to check whether it’s reversible• Must add state information– Can create composite commands• Editor macros– Can extend commands more easily174Command 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 process175Comparing Objects• Java has two designs for objects that can be(totally) ordered– These are things for which sorting makes sense– E.g., strings, integers, etc.176Comparablepublic interface Comparable {// Returns negative integer, zero, or a positive integer if thisobject is less than, equal to, or greater than o. public int compareTo(Object o);}• Advantages and disadvantages?– Can only implement one compareTo operation– No extra levels of indirection; objects know how tocompare themselves177Comparatorpublic interface Comparable { int compare(Object o1, Object o2);}• Advantages and disadvantages?– Can have multiple comparison operations– An example of delegation– Comparable needs to know innards of your objects• Can make the Comparable implementer an inner class– Extra indirection; more objects floating around178Pattern Hype• Patterns get a lot of hype and fanatical believers– We are going to have a design pattern reading group,and this week we are going to discuss the SingletonPattern!• Patterns are sometimes wrong (e.g., double-checked locking) or inappropriate for a particularlanguage or environment– Patterns developed for C++ can have very differentsolutions in Smalltalk or
View Full Document
Unlocking...