GoF Sections 2.7 – 2.9
description
Transcript of 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:
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
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
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
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
PasteCommand, Save Command, Quit Command subclasses of Command
User Operations
Glyph
MenuItemClicked()
CommandExecute()
command
User Operations
Can use Command to handle Undo/Redo Add Unexecute function to Command
interface Use a command history list
Cmd1 Cmd2 Cmd3 Cmd4
PresentFuturePast
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 wayslinked 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 interfaceFirst( ), Next( ), IsDone( ), CurrentItem( )
Subclasses ArrayIterator, ListIterator,PreorderIterator, PostorderIteratorImplement 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
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
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
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