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 • 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 command MenuItem Command Clicked() Execute()

10. User Operations • Can use Command to handle Undo/Redo • Add Unexecute function to Command interface • Use a command history list Cmd1 Cmd2 Cmd3 Cmd4 Past Future Present

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