GoF Sections 2.7 – 2.9

1. GoF Sections 2.7 – 2.9 More Fun with Lexi

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

3. Lexi Document Editor • Lexi tasks remaining: • User Operations • Spell checking and hyphenation

4. 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.

5. 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

6. 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

7. 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

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

10. User Operations

11. User Operations • Can use Command to handle Undo/Redo • Add Unexecute function to Command interface • Use a command history list

12. Cmd1 Cmd2 Cmd3 Cmd4 • . Past Future Present

13. 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

14. 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

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

16. 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

17. 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

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

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

21. 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

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

23. 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

24. 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

25. 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

27. 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<Character*>(glyph)) { // analyze the character } else if (r = dynamic_cast<Row*>(glyph)) { // prepare to analyze r's children } else if (i = dynamic_cast<Image*>(glyph)) { // do nothing } }

28. 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

29. 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:

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

31. 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); }

32. 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.

33. 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

34. 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

35. 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

36. 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