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

MenuItem

Clicked()

Command

Execute()

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 ways

linked 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 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

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