Chapter-II A Case Study:

Designing a Document Editor:

UNIT-II

DESIGN PATTERNS
B.TECH IV YR II SEMESTER(TERM 08-09) (CS05166) UNIT II PPT SLIDES
TEXT BOOKS: 1.Design Pattern by Erich Gamma, Pearson Education
2.Patterns in JAVA Vol-I BY Mark Grand, Wiley DreamTech 3.Patterns in JAVA Vol-II BY Mark Grand, Wiley DreamTech 4.JAVA Enterprise Design Patterns Vol-III Mark Grand, Wiley Dream Tech 5.Head First Design Patterns By Eric Freeman-Oreilly-spd.. 6.Design Patterns Explained By Alan Shalloway,Pearson Education
Mailing Lists
UNIT-II 2

S.NO. 1 2 3 4 5 6 7 8 9

TOPIC

PPT Slides L1 L2 L3 L4 L5 L6 L7 L8 L8 4 13 14 20 21 25 26 30 31 35 36 46 47 60 61 61 62 67

Document structure 20Formatting Embellishment Multiple look & feels Multiple window systems User operations Spelling checking & hyphenation Concluding Remarks Pattern References

UNIT-II

L1

Design Problems:
seven problems in Lexis's design: Document Structure:  The choice of internal representation for the document affects nearly every aspect of Lexis's design. All editing , formatting, displaying, and textual analysis will require traversing the representation. Formatting:  How does Lexi actually arrange text and graphics into lines and columns?  What objects are responsible for carrying out different formatting policies?  How do these policies interact with the documents internal representation? Embellishing the user interface: Lexis user interface include scroll bar, borders and drop shadows that embellish the WYSIWYG document interface. Such embellishments are likely to change as Lexis user interface evolves.

UNIT-II

L1

Design Problems
Supporting multiple look-and-feel standards: Lexi should adapt easily to different look-and-feel standards such as Motif and Presentation Manager (PM) without major modification. Supporting multiple window systems: Different look-and-fell standards are usually implemented on different window system. Lexis design should be independent of the window system as possible. User Operations: User control Lexi through various interfaces, including buttons and pull-down menus. The functionality beyond these interfaces is scattered throughout the objects in the application. Spelling checking and hyphenation.: How does Lexi support analytical operations checking for misspelled words and determining hyphenation points? How can we minimize the number of classes we have to modify to add a new analytical operation?
UNIT-II 5

Part II: Application: Document Editor (Lexi)

7 1. 2. 3. 4. 5. 6. 7. Design Problems Document structure Formatting Embellishment Multiple look & feels Multiple window systems User operations Spelling checking & hyphenation

L1

UNIT-II

L1

Document Structure
Goals:
present documents visual aspects drawing, hit detection, alignment support physical structure (e.g., lines, columns)

Constraints/forces:
treat text & graphics uniformly no distinction between one & many
UNIT-II 7

L1

Document Structure
The internal representation for a document The internal representation should support
maintaining the documents physical structure generating and presenting the document visually mapping positions on the display to elements in the internal representations

UNIT-II

L1

Document Structure (cont.)

Some constraints
we should treat text and graphics uniformly our implementation shouldnt have to distinguish between single elements and groups of elements in the internal representation

Recursive Composition
a common way to represent hierarchically structured information

UNIT-II

L1

UNIT-II

10

L1

Document Structure (cont.)

Glyphs
an abstract class for all objects that can appear in a document structure three basic responsibilities, they know
how to draw themselves, what space they occupy, and their children and parent

Composite Pattern
captures the essence of recursive composition in object-oriented terms
UNIT-II 11

L1

UNIT-II

12

L1

UNIT-II

13

L2

Formatting
A structure that corresponds to a properly formatted document Representation and formatting are distinct
the ability to capture the documents physical structure doesnt tell us how to arrive at a particular structure

here, well restrict formatting to mean breaking a collection of glyphs in to lines

UNIT-II 14

L2

Formatting (cont.)
Encapsulating the formatting algorithm
keep formatting algorithms completely independent of the document structure make it is easy to change the formatting algorithm Well define a separate class hierarchy for objects that encapsulate formatting algorithms
UNIT-II 15

L2

Formatting (cont.)
Compositor and Composition
Well define a Compositor class for objects that can encapsulate a formatting algorithm The glyphs Compositor formats are the children of a special Glyph subclass called Composition When the composition needs formatting, it calls its compositors Compose operation Each Compositor subclass can implement a different line breaking algorithm
UNIT-II 16

L2

UNIT-II

17

L2

Formatting (cont.)
Compositor and Composition (cont.)
The Compositor-Composition class split ensures a strong separation between code that supports the documents physical structure and the code for different formatting algorithms

Strategy pattern
intent: encapsulating an algorithm in an object Compositors are strategies. A composition is the context for a compositor strategy
UNIT-II 18

L2

UNIT-II

19

L2

UNIT-II

20

L3

Embellishing the User Interface

Considering adds a border around the text editing area and scrollbars that let the user view the different parts of the page here Transparent Enclosure
inheritance-based approach will result in some problems
Composition, ScollableComposition, BorderedScrollableComposition,

object composition offers a potentially more workable and flexible extension mechanism
UNIT-II 21

L3

Embellishing the User Interface (cont.)

Transparent enclosure (cont.)
object composition (cont.)
Border and Scroller should be a subclass of Glyph

two notions
single-child (single-component) composition compatible interfaces

UNIT-II

22

L3

Embellishing the User Interface (cont.)

Monoglyph
We can apply the concept of transparent enclosure to all glyphs that embellish other glyphs the class, Monoglyph

Decorator Pattern
void MonoGlyph::Draw(Window* w) { captures class and _component-> Draw(w); object relationships } that support void Border:: Draw(Window * w) { embellishment by MonoGlyph::Draw(w); transparent enclosure DrawBorder(w); 23 } UNIT-II

L3

UNIT-II

24

L3

UNIT-II

25

L4

Supporting Multiple Look-andFeel Standards

Design to support the look-and-feel changing at run-time Abstracting Object Creation
widgets two sets of widget glyph classes for this purpose
a set of abstract glyph subclasses for each category of widget glyph (e.g., ScrollBar) a set of concrete subclasses for each abstract subclass that implement different look-and-feel standards (e.g., MotifScrollBar and PMScrollBar)
UNIT-II 26

L4

Supporting Multiple Look-andFeel Standards (cont.)

Abstracting Object Creation (cont.)
Lexi needs a way to determine the lookand-feel standard being targeted We must avoid making explicit constructor calls We must also be able to replace an entire widget set easily We can achieve both by abstracting the process of object creation
UNIT-II 27

L4

Supporting Multiple Look-andFeel Standards (cont.)

Factories and Product Classes
Factories create product objects The example

Abstract Factory Pattern

capture how to create families of related product objects without instantiating classes directly
UNIT-II 28

L4

UNIT-II

29

L4

UNIT-II

30

Supporting Multiple Window Systems

Wed like Lexi to run on many existing window systems having different programming interfaces Can we use an Abstract Factory?

L5

As the different programming interfaces on these existing window systems, the Abstract Factory pattern doesn t work We need a uniform set of windowing abstractions that lets us take different window system impelementations and slide any one of them under a common interface
UNIT-II 31

Supporting Multiple Window Systems (cont.)

Encapsulating Implementation Dependencies
The Window class interface encapsulates the things windows tend to do across window systems The Window class is an abstract class Where does the implementation live?

L5

Window and WindowImp Bridge Pattern

to allow separate class hierarchies to work together even as they evolve independently
UNIT-II 32

L5

UNIT-II

33

L5

UNIT-II

34

L5

UNIT-II

35

L6

User Operations
Requirements
Lexi provides different user interfaces for the operations it supported These operations are implemented in many different classes Lexi supports undo and redo

The challenge is to come up with a simple and extensible mechanism that satisfies all of these needs
UNIT-II 36

L6

User Operations (cont.)

Encapsulating a Request
We could parameterize MenuItem with a function to call, but thats not a complete solution
it doesnt address the undo/redo problem its hard to associate state with a function functions are hard to extent, and its hard to reuse part of them

We should parameterize MenuItems with an object, not a function

UNIT-II

37

L6

User Operations (cont.)

Command Class and Subclasses
The Command abstract class consists of a single abstract operation called Execute MenuItem can store a Command object that encapsulates a request When a user choose a particular menu item, the MenuItem simply calls Execute on its Command object to carry out the request
UNIT-II 38

L6

UNIT-II

39

L6

UNIT-II

40

L6

User Operations (cont.)

Undoability
To undo and redo commands, we add an Unexecute operation to Commands interface A concrete Command would store the state of the Command for Unexecute Reversible operation returns a Boolean value to determine if a command is undoable

Command History
a list of commands that have been executed
UNIT-II 41

L6

Implementing a Command History

past commands

present

The command history can be seen as a list of past commands commands As new commands are executed they are added to the front of the history
UNIT-II 42

L6

Undoing the Last Command

unexecute()

present

present

To undo a command, unexecute() is called on the command on the front of the list The present position is moved past the last command
UNIT-II 43

L6

Undoing the Previous Command unexecute()

present present

To undo the previous command, unexecute() is called on the next command in the history The present pointer is moved to point before that command
UNIT-II 44

L6

Redoing the Next Command

execute()

present present

To redo the command that was just undone, execute() is called on that command The present pointer is moved up past that command
UNIT-II 45

L6

The Command Pattern

Encapsulate a request as an object The Command Patterns lets you
parameterize clients with different requests queue or log requests support undoable operations

Also Known As: Action, Transaction Covered on pg. 233 in the book
UNIT-II 46

L7

Spelling Checking & Hyphenation

Goals:
analyze text for spelling errors introduce potential hyphenation sites

Constraints/forces:
support multiple algorithms dont tightly couple algorithms with document structure
UNIT-II 47

L7

Spelling Checking & Hyphenation (contd)

Solution: Encapsulate Traversal

Iterator
encapsulates a traversal algorithm without exposing representation details to callers uses Glyphs child enumeration operation This is an example of a preorder iterator
UNIT-II 48

L7

Spelling Checking & Hyphenation (contd) TERATOR object behavioral Intent

access elements of a container without exposing its representation

Applicability
require multiple traversal algorithms over a container require a uniform traversal interface over different containers when container classes & traversal algorithm must vary independently

Structure

UNIT-II

49

L7

Spelling Checking & Hyphenation (contd) TERATOR (contd) object behavioral Iterators are used heavily in the C++ Standard Template Library (STL)
int main (int argc, char *argv[]) { vector<string> args; for (int i = 0; i < argc; i++) args.push_back (string (argv[i])); for (vector<string>::iterator i (args.begin ()); i != args.end (); i++) cout << *i; The same iterator pattern can be cout << endl; applied to any STL container! return 0; } for (Glyph::iterator i = glyphs.begin (); i != glyphs.end (); i++) UNIT-II ...

50

L7

Spelling Checking & Hyphenation (contd) TERATOR (contd) object behavioral Consequences
+ flexibility: aggregate & traversal are independent + multiple iterators & multiple traversal algorithms additional communication overhead between iterator & aggregate

Implementation
internal versus external iterators violating the object structures encapsulation robust iterators synchronization overhead in multi-threaded programs

batching in distributed & concurrent programs

Known Uses
C++ STL iterators JDK Enumeration, Iterator UNIT-II Unidraw Iterator
51

Spelling Checking & Hyphenation (contd)

L7

Visitor
defines action(s) at each step of traversal avoids wiring action(s) into Glyphs iterator calls glyphs accept(Visitor) at each node accept() calls back on visitor (a form of static polymorphism based on method overloading by type)
void Character::accept (Visitor &v) { v.visit (*this); } class Visitor { public: virtual void visit (Character &); virtual void visit (Rectangle &); virtual void visit (Row &); // etc. for all relevant Glyph subclasses }; UNIT-II

52

Spelling Checking & Hyphenation (contd)

L7

SpellingCheckerVisitor
gets character code from each character glyph Can define getCharCode() operation just on Character() class checks words accumulated from character glyphs combine with PreorderIterator
class SpellCheckerVisitor : public Visitor { public: virtual void visit (Character &); virtual void visit (Rectangle &); virtual void visit (Row &); // etc. for all relevant Glyph subclasses Private: std::string accumulator_; }; UNIT-II

53

L7

Spelling Checking & Hyphenation (contd)

Accumulating Words

Spelling check performed when a nonalphabetic character it reached

UNIT-II 54

Spelling Checking & Hyphenation (contd)

L7

Interaction Diagram
The iterator controls the order in which accept() is called on each glyph in the composition accept() then visits the glyph to perform the desired action The Visitor can be sub-classed to implement various desired actions

UNIT-II

55

L7

Spelling Checking & Hyphenation (contd)

HyphenationVisitor
gets character code from each character glyph examines words accumulated from character glyphs at potential hyphenation point, inserts a...

class HyphenationVisitor : public Visitor { public: void visit (Character &); void visit (Rectangle &); void visit (Row &); // etc. for all relevant Glyph subclasses };
UNIT-II 56

L7

Spelling Checking & Hyphenation (contd)

Discretionary Glyph
looks like a hyphen when at end of a line has no appearance otherwise Compositor considers its presence when determining linebreaks

UNIT-II

57

L7

Spelling Checking & Hyphenation (contd)

VISITOR
Intent

object behavioral

centralize operations on an object structure so that they can vary independently but still behave polymorphically

Applicability
when classes define many unrelated operations class relationships of objects in the structure rarely change, but the operations on them change often algorithms keep state thats updated during traversal

Structure

UNIT-II

58

Spelling Checking & Hyphenation (contd)

L7

VISITOR (contd)

object behavioral

SpellCheckerVisitor spell_check_visitor; for (Glyph::iterator i = glyphs.begin (); i != glyphs.end (); i++) { (*i)->accept (spell_check_visitor); } HyphenationVisitor hyphenation_visitor; for (Glyph::iterator i = glyphs.begin (); i != glyphs.end (); i++) { (*i)->accept (hyphenation_visitor); }
UNIT-II 59

L8

Spelling Checking & Hyphenation (contd)

VISITOR (contd)
Consequences
+ +

object behavioral

flexibility: visitor & object structure are independent localized functionality circular dependency between Visitor & Element interfaces Visitor brittle to new ConcreteElement classes double dispatch general interface to elements of object structure

Implementation

Known Uses
ProgramNodeEnumerator in Smalltalk-80 compiler IRIS Inventor scene rendering TAO IDL compiler to handle different backends UNIT-II

60

L8

Part III: Wrap-Up

Concluding Remarks
design reuse uniform design vocabulary understanding, restructuring, & team communication provides the basis for automation a new way to think about design

UNIT-II

61

Pattern References
Books Timeless Way of Building, Alexander, ISBN 0-19-502402-8 A Pattern Language, Alexander, 0-19-501-919-9

L8

Design Patterns, Gamma, et al., 0-201-63361-2 CD version 0-201-634988 Pattern-Oriented Software Architecture, Vol. 1, Buschmann, et al., 0-471-95869-7 Pattern-Oriented Software Architecture, Vol. 2, Schmidt, et al., 0-471-60695-2 Pattern-Oriented Software Architecture, Vol. 3, Jain & Kircher, 0-470-84525-2 Pattern-Oriented Software Architecture, Vol. 4, Buschmann, et al., 0-470-05902-8 Pattern-Oriented Software Architecture, Vol. 5, Buschmann, et al., 0-471-48648-5
UNIT-II

62

Pattern References (contd)

More Books Analysis Patterns, Fowler; 0-201-89542-0 Concurrent Programming in Java, 2nd ed., Lea, 0-201-31009-0 Pattern Languages of Program Design Vol. 1, Coplien, et al., eds., ISBN 0-201-60734-4 Vol. 2, Vlissides, et al., eds., 0-201-89527-7 Vol. 3, Martin, et al., eds., 0-201-31011-2 Vol. 4, Harrison, et al., eds., 0-201-43304-4 Vol. 5, Manolescu, et al., eds., 0-321-32194-4 AntiPatterns, Brown, et al., 0-471-19713-0 Applying UML & Patterns, 2nd ed., Larman, 0-13-092569-1 Pattern Hatching, Vlissides, 0-201-43293-5 The Pattern Almanac 2000, Rising, 0-201-61567-3
UNIT-II 63

L8

L8

Pattern References (contd)

Even More Books Small Memory Software, Noble & Weir, 0-201-59607-5 Microsoft Visual Basic Design Patterns, Stamatakis, 1-572-31957-7 Smalltalk Best Practice Patterns, Beck; 0-13-476904-X The Design Patterns Smalltalk Companion, Alpert, et al., 0-201-18462-1 Modern C++ Design, Alexandrescu, ISBN 0-201-70431-5 Building Parsers with Java, Metsker, 0-201-71962-2 Core J2EE Patterns, Alur, et al., 0-130-64884-1 Design Patterns Explained, Shalloway & Trott, 0-201-71594-5 The Joy of Patterns, Goldfedder, 0-201-65759-7 The Manager Pool, Olson & Stimmel, 0-201-72583-5
UNIT-II 64

L8

Pattern References (contd)

Early Papers
Object-Oriented Patterns, P. Coad; Comm. of the ACM, 9/92 Documenting Frameworks using Patterns, R. Johnson; OOPSLA 92 Design Patterns: Abstraction & Reuse of Object-Oriented Design, Gamma, Helm, Johnson, Vlissides, ECOOP 93

Articles
Java Report, Java Pro, JOOP, Dr. Dobbs Journal, Java Developers Journal, C++ Report

UNIT-II

65

L8

Pattern-Oriented Conferences
PLoP 2007: Pattern Languages of Programs October 2007, Collocated with OOPSLA EuroPLoP 2007, July 2007, Kloster Irsee, Germany See hillside.net/conferences/ for up-to-the-minute info.
UNIT-II 66

L8

Mailing Lists
patterns@cs.uiuc.edu: present & refine patterns patterns-discussion@cs.uiuc.edu: general discussion gang-of-4-patterns@cs.uiuc.edu: discussion on Design Patterns siemens-patterns@cs.uiuc.edu: discussion on Pattern-Oriented Software Architecture ui-patterns@cs.uiuc.edu: discussion on user interface patterns business-patterns@cs.uiuc.edu: discussion on patterns for business processes ipc-patterns@cs.uiuc.edu: discussion on patterns for distributed systems
See http://hillside.net/patterns/mailing.htm for an up-to-date list.
UNIT-II 67