1 / 26

GoF Sections 2.7 – 2.9

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:

rrhonda
Download Presentation

GoF Sections 2.7 – 2.9

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related