Basic Design Patterns

1. Basic Design Patterns 2. Designing a Document EditorGabriel MañanaEd. 453 Of. 120 Ext. 14080gjmananag @ unal.edu.co

2. Basic Design Patterns • Document Structure • Formatting • User Interface • Supporting Look & Feel Standards • Supporting Window Systems • User Operations • Spelling Checking & Hyphenation

3. Basic Design Patterns Document Structure (Composite) • The choice of internal representation for the document affects nearly every aspect of the editor’s design. • All editing, formatting, displaying and textual analysis will require traversing the representation. • The way we organize this information will impact the design of the rest of the application.

4. Document Structure text linecharstableimage ... paragraph column page

5. Document Structure The internal representation should support: • Maintaining the document’s physical structure, that is, the arrangement of text and graphics into lines, columns, tables, etc. • Generating and presenting the document visually • Mapping positions on the display to elements in the internal representation

6. Document Structure Constraints: • It should treat text and graphics uniformly • The implementation shouldn’t have to distinguish between single elements and groups of elements in the internal representation classes must have compatible interfaces

7. Glyph Character Polygon Row Rectangle draw(...)intersects(...) draw(Window w)intersects(Point p) draw(Window)intersects(Point)insert(Glyph, int) draw(...)intersects(...) draw(Window w)intersects(Point p) insert(Glyph, int) char c return true if pintersects thischaracter w->drawChar(c) insert g intochildren atposition i for all c in children if c->intersects(p) return true for all c in children ensure c position c->draw(w) children Recursive Composition

8. Composite Pattern • Recursive composition is good for more than just documents. It can be used to represent any potentially complex, hierarchical structure. • The Composite pattern captures the essence of recursive composition in object-oriented terms.

9. Basic Design Patterns Formatting (Strategy) • How does the editor 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 document’s internal representation?

10. Basic Design Patterns Formatting Responsibility Operation what to format void setComposition( Composition ) when to format void compose() • we’ll define a Compositor class for objects that can encapsulate a formatting algorithm • the glyphs it formats are the children of a special Glyph subclass called Composition

11. Glyph Composition Compositor SimpleCompositor ArrayCompositor TeXCompositor compose() compose() compose() compose()setComposition() insert(Glyph, int) insert(Glyph, int) Glyph::insert(g, i)compositor.compose() Strategy children compositor composition

12. Strategy Pattern • Encapsulating an algorithm in an object is the intent of the Strategy pattern. • The key participants in the pattern are strategy objects and the context in which they operate. • Compositors are strategies; they encapsulate different formatting algorithms. A Composition is the context for a Compositor strategy.

13. Basic Design Patterns User Interface (Decorator) • The editor’s UI includes scroll-bars, borders and drop shadows. • Such embellishments are likely to change as the editor’s UI evolves. • Hence it is important to be able to add and remove embellishments easily without affecting the rest of the application.

14. Basic Design Patterns User Interface • Embellishing the users interface involves extending existing code. • Using inheritance to do such extension precludes rearranging embellishments at run-time. • An equally serious problem, is the explosion of classes that can result from an inheritance-based approach.

15. Composition ScrollableComposition BorderedCompsosition

16. Composition ScrollableComposition BorderedCompsosition BorderedScrollableComposition

17. User Interface Object composition offers a potentially more workable and flexible extension mechanism: • Since we know we’re embellishing an existing glyph, we could make the embellishment itself an object (class Border f.i.) • Glyph and Border: the next step is to decide who composes whom • If we put the Border in the Glyph then we must make modifications to all Glyph subclasses to make them aware of the border

18. User Interface All this lead us to the concept of transparent enclosure, which combines the notions of single child (or single-component) composition, and compatible interfaces Clients generally can’t tell whether they’re dealing with the component or its enclosure: the enclosure delegates all its operations to its component and augments the component’s behaviour by doing work of its own (before or after) delegating an operation.

19. Glyph MonoGlyph Scroller Border draw(Window) draw(Window) draw(Window) draw(Window)drawBorder(Window) Monoglyph component

20. Decorator Pattern • The Decorator pattern captures class and object relationships that support “embellishment” by transparent enclosure. • In the Decorator pattern, “embellishment” referes to anything that adds responsibilities to an object.

21. Basic Design Patterns Supporting multiples L&F Standards(Abstract Factory) • The editor should adapt easily to different look-and-feel standards such as Motif and Windows GUI without major modification.

22. GUIFactory MotifFactory WindowsFactory MacFactory createButton()createMenu()... createButton()createMenu()... createButton()createMenu()... createButton()createMenu()... return new MotifMenu return new MotifButton return new WindowMenu return new WindowButton return new MacMenu return new MacButton FactoryHierarchy

23. Glyph WindowsMenu Button Menu MacMenu MotifButton MacButton MotifMenu WindowsButton ... pressed()... popup()... pressed()... popup()... pressed()... popup()... pressed()... popup()... ProductHierarchy

24. Abstract Factory Pattern • Factories and Products are the key participants in the Abstract Factory pattern. • This pattern captures how to create families of related product objects without instantiating classes directly. • It’s most appropriate when the number and general kinds of products objects stay constant, and there are differences in specific product families.

25. Abstract Factory Pattern • The Abstract Factory pattern’s emphasis on families of products distinguishes it from other creational patterns, which involve only one kindof product object.

26. Basic Design Patterns Supporting multiples Window Systems(Bridge) • Different look-and-feel standards are usually implemented on different window systems. • The editor’s design should be as independent of the window system as possible.

27. Basic Design Patterns Can we use an Abstract Factory? • At first glance this may look like another opportunity to apply the Abstract Factory pattern. • But the constraints for window system portability differ significantly from those for look-and-feel independence.

28. Basic Design Patterns Answer: NO • In applying the Abstract Factory pattern, we assumed that we would define the concrete widget glyphs classes for each L&F standard. • It’s highly unlikely that window class hierarchies from different vendors are compatible in any way.Hence, we won’t have a common abstract product for each kind of widget (ScrollBar, Button, etc.)

29. Basic Design Patterns • We have to make the different widget hierarchies adhere to a common set of abstract product interfaces.Only then could we declare the create...() operations properly in our abstract factory’s interface.We need a uniform set of windowing abstractions that let us take different window system implementations and slide any one of them under a common interface.

30. Basic Design Patterns Encapsulating Implementation Dependencies The Window class encapsulates the things that windows tend to do across window systems: • Provide operations for drawing basic geometric shapes • Iconify and de-iconify themselves • Resize themselves • (Re)draw their contents on demand

31. Basic Design Patterns Two extreme philosophies: The Window class must span the functionality of windows from different window systems: Intersection of functionalityThe window class provides only functionality that’s common to all window systems Union of functionalityCreate an interface that incorporates the capabilities of all window systems

32. Basic Design Patterns Window class interface Responsibility Operations windowmanagement virtual void redraw()virtual void raise()virtual void lower()virtual void iconify()virtual void deiconify()... graphics virtual void drawLine()virtual void drawRect()virtual void drawText()...

33. Glyph Window IconWindow DialogWindow FrameWindow draw( Window ) redraw()iconify()...drawLine()drawText()... iconify() lower() owner->lower() glyph->draw( this ) glyph owner

34. Basic Design Patterns Now we have defined a window interface for the document editor to work with, where does the real platform-specific window come in?We can do the same thing we did for formatting and embellishment, namely, encapuslate the concept that varies.

35. Window IconWindow DialogWindow FrameWindow WindowImp XWindowImp MSWindowImp MacWindowImp raise()...drawText()... deviceRaise()...deviceText()... deviceRaise() deviceRaise() deviceRaise() imp

36. Bridge Pattern • The intent behind Bridge is to allow separate class hierarchies to work together even as they evolve independently.The Bridge pattern lets us maintain and enhance our logical window abstractions without touching window system-dependent code, and vice versa.

37. Basic Design Patterns User Operations (Command) • Users control the editor through various user interfaces, including buttons and pull-down menus. • The functionality behind these interfaces is scattered throughout the objects in the application. • The challenge here is to provide a uniform mechanism both for accessing this scattered functionality and for undoing its effects.

38. Command PasteCommand FontCommand SaveCommand execute() execute()---------------m_buffer execute()---------------m_font execute() paste m_bufferinto document make selectedtext appear inm_font pop up a dialogbox that lets theuser name the document and then save the document CommandHierarchy

39. Glyph MenuItem Command clicked() execute() command->execute() MenuItem-Command command

40. Command Pattern • The Commandpattern describes how to encapsulate a request.It prescribes a uniform interface for issuing requests that lets you configure clients to handle different requests. The interface shields clients from the request’s implementation.

41. Basic Design Patterns Spelling Checking and Hyphenation(Iterator/Visitor) • How does the editor support analytical operations such as 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?

42. Basic Design Patterns Spelling Checking and Hyphenation • As was the case with line-breaking strategies, there’s more than one way to check spelling and compute hyphenation points. • So here too we want to support (and add easily) multiple algorithms. • We also want to avoid wiring this functionality into the document structure.

43. Basic Design Patterns Spelling Checking and Hyphenation There are actually two pieces to this puzzle: accessing the information to be analyzed, which we have scattered over the glyphs in the document structure, and doing the analysis.

44. Basic Design Patterns Spelling Checking and Hyphenation • The text we need to analyse is scattered throughout a hierarchical structure of glyphs objects. • Some glyphs might store their children in linked lists, others might use arrays, and still others might use more esoteric data structures. • The access mechanism must be able to handle all of these possibilities.

45. Basic Design Patterns Encapsulating Access and Traversal • An important role of the glyphs abstraction is to hide the data structure in which children are stored. • That way we can change the data structure a glyph class uses without affecting other classes. • We can solve this problem and support several different kinds of traversals at the same time.

46. Basic Design Patterns Encapsulating Access and Traversal • We can add the following abstract operations to the Glyph’s interface: void first( Traversal ) void next() boolean isDone() Glyph current() void insert( Glyph )

47. Iterator Glyph NullIterator PreorderIterator ListIterator first()next()isDone()current() first()next()isDone()current() first()next()isDone()current() first()next()isDone()current() ...createIterator() return new NullIterator glyph->draw( this ) return true 1..* iterators ArrayIterator first()next()isDone()current() currentItem 1..* 1..* root

48. Iterator Pattern • The Iteratorpattern captures the techniques for supporting access and traversal over object structures.It’s applicable not only to composite structures but to collections as well.

49. Iterator Pattern • The Iteratorpattern abstracts the traversal algorithm and shields clients from the internal structure of the objects (containers) they traverse.It illustrates once more how encapsulating the concept that varies helps us gain flexibility and reusability.

50. Basic Design Patterns Traversal vs. Traversal Actions • Now that we have a way of traversing the glyph structure we can check the spelling and do the hyphenation. • Both analyses involves accumulating information during the traversal. • First we have to decide where to put the responsibility for analysis (1. iterator classes, 2. glyph classes, 3. separate class).