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
• Cant 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 Lexis needs?
• Doesnt 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
Future
Past
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 youre sure the
  objects youre 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