Lexi case study (Part 2) Presentation by Matt Deckard

User Operations  Support different operations  Cut, copy, paste  Formatting  Printing  Etc.  Support different Uis  Menus  Buttons  Keyboard shortcuts  Etc.

User Operations  Avoid coupling operations and UIs  Use multiple UIs for single operations  Change UIs in the future  Avoid creating dependencies to classes operations are defined in  Undo and Redo  Want some, but not all operations to be undoable  Un-undoable operations:  Saving  Creating new documents  Printing  Don’t want arbitrary limit on levels of undo

User Operations  Encapsulate user operations  GUI menus are just glyphs that perform actions in response to user interaction  Create subclass of Glyph called MenuItem  But don’t want to make each operation a subclass of MenuItem (avoid decoupling!)  Parameterize menu items by uper operations  How?

User Operations  How should user operations be parameterized?  Simple function call has drawbacks:  Doesn’t address undo/redo  Hard to associate state with function  Difficult to extend, reuse  Use objects instead  Can store state, implement undo/redo  Use inheritance to extend, reuse

Command class  Command: abstract class representing user operation  Based on abstract method Execute()  Subclasses will implement Execute() according to the operation they represent  Subclasses can delegate parts of user operation to other objects  Command objects are treated uniformly by requestor  MenuItem will store instance of Command object to encapsulate its associated user operation

Command class  Undoability  Add abstract Unexecute() method  During Execute(), Commands will store whatever information they need to undo later  Add abstract Reversible() method  Returns true if and only if this Command is undoable  Allows Commands to determine undoability at runtime  i.e. redundant or vacuous Commands shouldn’t be undoable  Command history  Need list of Commands to support multiple undos  Traverse back and forth through list to undo and redo  Call Unexecute() when undoing, Execute() when redoing

Command class

Command Pattern  Encapsulates a request (user operation)  Prescribes uniform interface for requests  Shields clients from request’s implementation  Allows delegation of request to other objects  Provides centralized access to functionality  Allows to queue or log requests  Supports undo, redo  AKA “Action”, “Transaction”  Similar to functor (but not quite the same)

Command Pattern  Related patterns  Use with Composite and you’ve got: macros!  Use with Memento to remember state (for undo)  Use Prototype to copy command before putting in undo list, to distinguish multiple invocations of same command

Spellchecking and Hyphenation  Textual analysis  Want to support multiple algorithms, addition of new ones in future  Avoid coupling to document structure  Add other types of analysis in future  i.e. search, word count, etc.  Two pieces:  Accessing information to be analyzed  Performing the analysis

Accessing scattered information  Data access  Glyphs may be stored in different ways  Need mechanism to access all of them  Traversal  Different analyses may access Glyphs in different ways (i.e. forward vs. reverse search)  Issues  Only Glyphs know their data structure  Glyph interface shouldn’t be biased toward one structure over another  i.e. using integer index biased us toward arrays  Want to provide multiple access and traversal methods

Accessing scattered information  One approach: adding methods to Glyph  void First(Traversal) – initializes specified traversal  void Next() – advances to next Glyph in traversal  bool IsDone() – reports if traversal is over  Glyph* GetCurrent() – accesses current glyph  Replaces Child()  void Insert(Glyph*) – inserts Glyph at current pos  Replaces Insert(Glyph*, int)

Accessing scattered information  Issues with this approach  Must extend Traversal enumeration to support new traversals  Would also have to change lots of subclasses  Difficult to reuse mechanism for other object structures  Doesn’t support multiple traversals in parallel

Iterator class  Better approach: encapsulate access and traversal  Iterator  Abstract class  Defines interface for access and traversal  Subclass contains reference to structure it traverses  CreateIterator()  By default, will return NullIterator  Subclasses can override, based on their structure  Iterators can use CreateIterator() on their root glyphs to support different traversal

Iterator class  Example: PreorderIterator  First()  Calls CreateIterator() on root  Calls First() on returned Iterator  Pushes Iterator onto stack  CurrentItem()  Calls CurrentItem() on Iterator at top of stack  Returns result  Next()  Calls CreateIterator() on top Iterator  Calls First() on returned Iterator  Pushes Iterator onto stack  Calls IsDone() on latest Iterator. If true, pops it off and repeats

Iterator class

Iterator Pattern  Abstracts traversal algorithm  Shields clients from internal structure of objects traversed  Gain flexability, usability  Easy to extend  Easy to reuse by parameterizing object type  Can perform multiple traversals in parallel

Performing the analysis  Want to distinguish analysis from traversal  Flexibility, reusability  Different analyses might require same traversal  Want to distinguish different types of glyphs  Different analyses consider different glyphs  Could abstract in Glyph, have subclasses implement  Drawbacks to this approach:  Have to change multiple subclasses  Obscures basic glyph interface

Performing the analysis  Encapsulate the analysis  Create analysis classes  For now, let’s consider a SpellChecker class  Iterator has instance of SpellChecker  Uses SpellChecker instance as it traverses  SpellChecker accumulates information as it is used

Performing the analysis  How to distinguish glyphs?  SpellChecker treats different glyph types differently  Don’t want to resort to type tests or casting (gross)  Instead, have the glyph object tell SpellChecker to check it  Glyph has abstract CheckMe() method  SpellChecker has methods for every glyph subclass, i.e. CheckCharacter(), CheckRow(), CheckImage(), etc.  Glyph sublcasses will override CheckMe() to call the appropriate method in SpellChecker

Performing the analysis

 Adding new analyzers  Will be difficult if we define them as separate classes  Instead, abstract it as a Visitor class  CheckMe() becomes the Accept() method  Takes any Visitor as parameter, so don’t have to touch glyph subclasses when adding new analyzers  CheckCharacter(), etc become the Visit() method  Overloaded, takes visited subclass as parameter  Need one for every subclass that implements Accept()

Visitor Pattern  Can be applied to any object structure  Visitees needn’t have common parent class  Tradeoff:  When you add Visitors you don’t have to update object structure, BUT:  When you add subclasses to object structure, you DO have to update your Visitor classes  Sometimes can provide default “do nothing” operation in Visitor  Helps avoid “polluting” classes with many operations  Helps to separate groups of common operations  Can accumulate state as they visit elements  Sometimes compromises encapsulation of visitee  elements

Summary  Needed to support different user operations  Encapsulate the concept that varies (Command)  Needed to support different methods of accessing and traversing data  Encapsulate the concept that varies (Iterator)  Needed to support different analysis algorithms  Encapsulate the concept that varies (Visitor)  (Are we seeing a pattern here?)