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  Subclass Glyph with MenuItem One possible approach  Have a subclass of MenuItem for each type of user operation that handles 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 PasteCommand, Save Command, Quit Command subclasses of Command

9. User Operations Glyph MenuItem Clicked() Command Execute() command

10. User Operations Can use Command to handle Undo/Redo Add Unexecute function to Command interface Use a command history list Cmd1Cmd2Cmd3Cmd4 Present FuturePast

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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