GoF Sections 2.7 – 2.9 More Fun with Lexi

Lexi Document Editor Lexi tasks discussed:  Document structure  Formatting  Embellishing the user interface  Supporting multiple look-and-feel standards  Supporting multiple window systems

Lexi Document Editor Lexi tasks remaining:  User Operations  Spell checking and hyphenation

User Operations Large variety in functionality  Create a new document  Cut and Paste selected document text  Change the font of selected text  Change the format of selected text  Change alignment and justification  Quit application  Etc.

User Operations Different user interfaces for these operations Want to avoid coupling particular user operation with a particular user interface  Could use multiple user interfaces for same operation  May want to change the interface in the future Theses operation are implemented in different classes. We want to access their functionality without creating a lot of dependencies (avoid tight coupling) Want ability to undo/redo (some) operations  Can’t undo quitting the application  Should be no limit on number of levels available

User Operations So how do we handle these? Treat a pull-down menu as a type of glyph ( The difference with other composite glyphs is that they do some work when they are clicked on)  Subclass Glyph with MenuItem (special glyphs that do some operations) One possible approach  Have a subclass of MenuItem for each type of user operation and hard code each subclass to handle each request Does this work?  Couples the request to a particular user interface

User Operations Approach 2: Give MenuItem class a function to call to perform the operation Gives more run-time flexibility Does it suit Lexi’s needs?  Doesn’t address undo/redo problem  Difficult to associate state with a function  Functions are difficult to extend

User Operations A better way Parameterize MenuItems with a Command object Addresses the 3 issues just discussed  Undo/redo  Store state  Extend through inheritance

User Operations

Can use Command to handle Undo/Redo Add Unexecute function to Command interface Use a command history list

. Cmd1Cmd2Cmd3Cmd4 Present FuturePast

User Operations The Command Pattern (GoF, pg 233) Intent:  Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations

Spell Check & Hyphenation Lexi needs ability to spell check and improve formatting Constraints  Need to support multiple algorithms  Should be easy to add new algorithms  Should be able to add new kinds of analyses Searching Word Counting Grammar Check

Spell Check & Hyphenation 2 main pieces to address  How to access the information to be analyzed  How to do the actual analysis

Spell Check & Hyphenation Accessing the information Data is scattered in the Glyph objects Problems  Glyphs can store children in multiple ways linked list, arrays, etc  Not all traversals will be beginning to end Must allow differing data structures Must support differing traversals

Spell Check & Hyphenation Put the traversal operations in the glyph classes? Encapsulate the concept that varies: The access and traversal mechanisms Have Iterator classes do the work

Spell Check & Hyphenation Abstract Iterator class w/ general interface First( ), Next( ), IsDone( ), CurrentItem( )

Subclasses ArrayIterator, ListIterator, PreorderIterator, PostorderIterator Implement the access and traversals Subclass contains reference to the structure it will traverse CreateIterator( ) added to Glyph interface

Spell Check & Hyphenation The Iterator Pattern (GoF, pg 257) Intent:  Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation

Spell Check & Hyphenation Now, how do we analyze the data accessed? We can put the analysis in the Iterator classes Will this work?

Spell Check & Hyphenation Want to keep analysis separate from the traversal Also need to be able to distinguish between different glyph types Solution:  Encapsulate the analysis in an object

But where to put this object? - One solution is to add analysis ability to the Glyph. For each analysis we can add a one or more abstract operations to the Glyph class. Problem: We need to change glyph class whenever we add a new kind of analysis. Other problem: Glyph interfaces grow over time and deviates from the initial purpose

Spell Check & Hyphenation Use the analysis object in conjunction with the iterator Iterator brings the object along to analyze as it traverses the glyphs Analyzer gathers pertinent info as the traversal proceeds

The fundamental question with this approach is how the analysis object distinguishes different kinds of glyphs without resorting to type tests or downcasts. We don't want a SpellingChecker class to include ugly (pseudo)code like: void SpellingChecker::Check (Glyph* glyph) { Character* c; Row* r; Image* i; if (c = dynamic_cast (glyph)) { // analyze the character } else if (r = dynamic_cast (glyph)) { // prepare to analyze r's children } else if (i = dynamic_cast (glyph)) { // do nothing }

Spell Check & Hyphenation Define the abstract Visitor class for performing the analysis Contains Visit_____ ( ) operations for each glyph subclass Concrete subclasses include SpellingCheckerVisitor and Hyphenation Visitor Add an abstract CheckMe( Visitor& ) operation to the Glyph class  Eliminates need for analyzer to type check each glyph it encounters

So Let’s add the following abstract operation to the Glyph class: void CheckMe(SpellingChecker&) We define CheckMe in every Glyph subclass as follows: void GlyphSubclass::CheckMe (SpellingChecker& checker) { checker.CheckGlyphSubclass(this); } Where CheckGlyphsubclass is replaced by the glyph subclass name as follows:

class SpellingChecker { public: SpellingChecker(); virtual void CheckCharacter(Character*); virtual void CheckRow(Row*); virtual void CheckImage(Image*); //... and so forth List & GetMisspellings(); protected: virtual bool IsMisspelled(const char*); private: char _currentWord[MAX_WORD_SIZE]; List _misspellings; };

Now we can traverse the glyph structure, calling CheckMe on each glyph with the spelling checker as an argument. This effectively identifies each glyph to the SpellingChecker and prompts the checker to do the next increment in the spelling check. SpellingChecker spellingChecker; Composition* c; //... Glyph* g; PreorderIterator i(c); for (i.First(); !i.IsDone(); i.Next()) { g = i.CurrentItem(); g->CheckMe(spellingChecker); }

Spell Check & Hyphenation The Visitor Pattern (GoF, pg 331) Intent:  Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Spell Check & Hyphenation What happens to our Visitor class if a new Glyph subclass is added? Forced to update all Visitor classes with a new VisitNewGlyph( ) operation Therefore, best to use Visitor if you’re sure the objects you’re working on (in this case Glyphs) have a stable class structure

Lexi Summary Composite  Represent the documents physical structure Strategy  Allow different formatting algorithms Decorator  Embellish the user interface Abstract Factory  Support multiple look-and-feel standards

Lexi Pattern Summary Bridge  Allow multiple windowing platforms Command  Undoable user operations Iterator  Accessing and traversing object structures Visitor  Allow open-ended number of analytical tasks

Lexi Pattern Summary Worth noting, these patterns are not limited to the Lexi program The patterns are (easily) adapted to many other common designs  Decorator and Command used in Lexi as they would in any typical application with a GUI