GoF: 2.1-2.6 Document Editor Example

1. GoF: 2.1-2.6Document Editor Example A Case Study

2. Designing Lexi, a WYSIWYG Document Editor • The purpose is to show how design patterns capture solutions to design problems in lexi • The document can mix text and graphics freely in a variety of formatting styles. It has pull-down menus, scroll bars and collection of page icons for navigation in the document.

4. Document Editor • What are your first thoughts about how to build a document editor? • Internal structure • Formatting • Gui • Spell Check

5. Design Problems • Document Structure • Internal structure; will affect every aspect of the design of Lexi, need to traverse • Formatting • Need to arrange text and graphics into lines & columns • Which objects carry out formatting • How interact with internal representation

6. Design Problems • Embellishing the user interface • Scroll bars, borders etc • Independent of the rest of the application • Embellishments likely to change as Lexi evolves • Support multiple look-and-feel (motif, java, pm,..) • Support multiple window systems (MS window, X, mac, ..)

7. Design Problems • User Operations • Buttons, pull-down menus, Uniform access with undo capability • Spelling checking and hyphenation

8. Document Structure • Arrangement of graphical elements (characters, lines, polygons, etc..) • An author however views theses as document’s physical structure- lines, columns, figures, tables, and other substructures (not in graphical terms) So, Users need to treat collection and single elements the same. For example user should be able to refer to a table as a whole not as an unstructured mass of text and graphics.

9. Document Structure • Internal Representation need to support: • Maintaining document’s physical structure, that is, the arrangement of text and graphics into lines and columns, tables, etc • Generating and presenting visually • Map position on the display to the internal representation (lexi would know what s being pointed to)

10. Document structure • We should treat text and graphics uniformly • We should not have to distinguish between a single element and a group of elements in the internal representation. ( e.g. the tenth element in line five of column two could be a single character or a complex diagram) -- As long as an element can draw itself and set its dimensions, its complexity should not affect where it appears • Opposing the above is to analyze for spell checking

11. Document Structure • Use Recursive Composition A technique to represent a hierarchy of structured information Building increasingly complex elements out of simpler ones. e.g. we can tile a set of characters and graphics to form a line. Multiple lines can be arranged to form columns, multiple columns to form a page, etc

13. Document Structure • We can assign an object to each important element, also to invisible structural elements such as line, column, etc..

14. Two implications: 1- These Objects need corresponding classes 2- These classes must have compatible interfaces, if we want to treat them uniformly, So the classes must be related through inheritance, possibly through an abstract class.

15. Document Structure • Glyphs: An abstract class for • Primitive graphical elements, and • Structural elements

18. Document Structure Glyph Responsibilities: • Draw themselves Each know how to render itself on the screen • Where they are, how much space they occupy A parent glyph needs to know how much space a child occupies, for example to arrange it in line • Children and parent We need interfaces to add and remove and access children. A line’s children are the glyphs arranged into a row.

19. Glyph Subclasses redefine Draw to render themselves on the window Void Rectangle::Draw(Window* w) { W-> DrawRect(_x0, _y0, _x1, _y1); }

20. Document Structure • Are there any problems with these Glyphs? • Strict hierarchy • Object for every character (efficiency) • Could share Glyphs • Flyweight Pattern: share objects between different contexts; operation takes extrinsic state; objects represent internal state

21. Composite Pattern • Recursive composition can be used to represent any potentially complex hierarchical structure. • Composite pattern captures the essence of recursive composition in OO terms.

22. Formatting • We have so far settled on how to represent the document’s physical structure • Next we need to decide on how to construct the document’s physical structure (Formatting) • These two are distinct

23. Formatting • Formatting: breaking collection of glyphs into lines, lines into columns, etc • For example, the user might vary margin, single or double space, indentation, etc

24. Formatting • Formatting is a complex task. There are variety of algorithms • Trade-offs: quality, speed • Many new might be invented • We need to keep formatting algorithm well contained, completely independent of document structure

25. Formatting • We should be able to add a new glyph subclass without regard to formatting algorithm, and conversely adding a new algorithm should not require changing existing glyphs

26. Formatting • So, we should design Lexi so that it’s easy to change the formatting algorithm (at compile-time, event at run-time). To do this: • We can isolate the algorithm and make it easily replaceable by encapsulating it in an object

27. Formatting • More specifically, we’ll define a separate class hierarchy of algorithm objects. • The root will contain interfaces for a wide range of formatting algorithms, and each subclass will implement a particular algorithm. • Then we can introduce a new Glyph subclass that will structure its children automatically using a given algorithm object

28. Formatting • Encapsulating Format algorithm • Compositor: class for formatting algorithm objects • What glyphs to format and when to do the formatting

29. Formatting

30. Formatting Composition: special glyph subclass • It formats children of a special glyph subclass called composition • A composition gets an instance of a Compositor (e.g specific line-breaking algorithm) when created and tells compositor to compose its glyphs

31. Formatting

32. Formatting • How it works: An unformatted object contains only visible glyphs, not Rows or columns. The composition is in this state just after initialized with the glyphs it should format. It then calls its compositor’s compose operation to format it’s children according to a particular algorithm.

33. Formatting column row row

34. Formatting • Compositor-Composition ensures strong separation between physical representation and formatting • We can even change algorithm at run-time by adding a single SetCompositor operation to composition’s basic glyph interface

35. Formatting • Strategy Pattern • Objects encapsulate algorithms and the context in which they operate • Compositors are strategies, • A Composition is the context for compositor strategy • The Key is to design interface to support range of algorithms. Shouldn’t have to change the strategy or context interface to support a new algorithm.

36. Embellishing the User Interface • Border and Scrollbar • Easily add and remove • No inheritance (run-time, lots of classes) To easily add and remove embellishments specially at runtime we should not use inheritance. We should be able to add and remove embellishments without changing other classes.

37. Embellishing the User Interface • We could add a border to composition by sub-classing it (BorderedComposition class), or the same way for scrollbar to get ScrollableComposition • Subclass it again to get ScrollableBorderedComposition Class Problem: we end up a class for every possible combination, an unworkable solution

38. Embellishing the User Interface • Object composition potentially more workable (embellishment is object) Who composes whom? • Border contain Glyph? • Glyph contain Border? (need to modify glyph class to be aware of border) First choice keeps the border-drawing code entirely in the Border class leaving other classes alone

39. Embellishing the User Interface • Borders have an appearance, so they should actually be glyphs (Border should be subclass of Glyph) • In addition clients should not care whether Glyph have borders or not. If a glyph is composed in a border, clients should not treat it differently than a plain glyph So, we need to subclass Border from Glyph to guarantee this

40. Embellishing the User Interface All this leads us to the concept of: • Transparent enclosure • 1) single child (or single component) composition • 2) compatible interfaces(clients can’t tell if they are dealing with a component or it’s enclosure.)

41. Embellishing the User Interface • Enclosure can augment component’s behavior by doing work before and/or after delegating an operation.. So we define a new subclass of Glyph, the MonoGlyphto serve as an abstract class for embellishment glyph. • MonoGlyph (subclass of glyph) • Stores reference to a component (glyph) and forwards requests to it (see the code)

42. Embellishing .. Void MonoGlyph::Draw (window* w) { -component->Draw(w);} • Performs embellishment before or after sending glyph the request (draw itself) Void MonoGlyph::Draw (window* w) { -component->Draw(w); DrawBorder(w);}

43. Embellishing the User Interface • The same way we define another Monoglyph, the scroller. • We put composition instance in the scroller instance, and the resulting composition in the Border instance.

44. Embellishment.. Question: Should border contain scroller or the reverses? Result: Transparent enclosure keeps clients free of embellishment code.

45. Embellishing the User Interface • Decorator Pattern • Attach additional responsibilities to object dynamically • Enclose component in another component • Nest decorators recursively • Forwards requests to component • Can perform additional actions before or after

46. Supporting Multiple Look-and-Feel Standards • Portability across hardware and software platforms is a major problem in system design. Part of portability is supporting multiple user interface style guides on each platform. • Look-and-feel standards define guidelines for how applications appear and react to the user. • Lexi should support multiple existing look-and-feel standards and make it is to support future ones • Also support changing look-and-feel at runtime

47. Supporting Multiple Look-and-Feel Standards • Everything we see in Lexi is a glyph composed in some invisible glyph. look-and-feel style guides deal with “widgets”, visible glyphs such as buttons,etc We assume we have 2 sets of widget glyph classes: • Set of abstract glyph subclass for each widget category • Set of concrete subclasses to implement different standards

48. Supporting Multiple Look-and-Feel Standards • Lexi needs to use different concrete widget glyphs for different look-and-feel, for example, MotifButton, PMButton, MacButton, etc • But How? Can Lexi create theses directly in say a constructor? - Hard-coding the button of particular style make it impossible to select the style at run-time ( e.g scrollBar* sb= new MotifScrollBar;) - We also have to track down and change every such constructor call to port to another platform - Littering code with constructor calls to specific look-and-feel classes yields a maintenance nightmare

49. Supporting Multiple Look-and-Feel Standards 1- We Must avoid making explicit constructor calls 2- We must be able to replace an entire widget set easily We can achieve both by: abstracting the process of object creation

50. Supporting Multiple Look-and-Feel Standards Example (C++): Scrollbar* sb= new MotifScrollbar; (this is what we want to avoid) But suppose we do this: Scrollbar* sb= guiFactory->CreateScrollbar(); Where guiFactory is an instance of MotifFactory class. For Clients the effect is the same, but there is one crucial difference: There is no mentioning of Motif by name in the code.