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.

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

4. 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

5. 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, ..)

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

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

8. 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)

9. 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

10. 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 for a page, etc

11. Document Structure • We can assign an object to each important element, also to invisible structural elements such as line, column, etc.. (The result shown in figure 2.3) • 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.

12. Document Structure • Glyphs: An abstract class for • Primitive graphical elements, and • Structural elements Figure 2.4, the class hierarchy, Table 2.1 glyph interface

13. Document Structure 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.

14. 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

15. 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.

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

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

23. Formatting

24. 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

25. Formatting Figure 2.5 – composition- compositor class relationships Glyph

26. 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. Figure 2-6, shows glyphs generated by compositor

27. Formatting composition compositor • Figure 2.6 column row row G g space

28. 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

29. 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.

30. 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.

31. 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

32. 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

33. 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

34. 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.)

35. 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) • Performs embellishment before or after sending glyph the request (draw itself) (see the code)

36. 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)

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

38. 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. (Figure 2.8 shows the resulting object structure) Question: Should border contain scroller or the reverses? Result: Transparent enclosure keeps clients free of embellishment code.

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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.

45. Supporting Multiple Look-and-Feel Standards • guiFactory objects abstract the process of creating scrollbars for any look-and-feel standard. And it can manufacture any widget glyph for that standard. Figure 2-9 shows GUIFactory class heierachy for guiFactory objects. • Factories make product objects that are related (belong to the same look-and-feel in this case)

46. Supporting Multiple Look-and-Feel Standards • Question: Where doe GUIFactory instance come from? Answere:Anywhere convenient, guiFactory can be a global, an static member of a well known class, or a Singleton object ( another design pattern) The important point is to initialize before it’s used and after it’s clear which look-and-feel is desired. (Look at the initialization code next slide) If we change our mind, we can reinitialize guiFactory and get a new look-and-feel at runtime

47. Supporting Multiple Look-and-Feel Standards GUIFactory* guiFactory; const char* styleName= getenv(*LOOK_AND_FEEL*); If (strcmp(styleName, “Motif”) == 0) { guiFactory=new MotifFactory; } else if (strcmp(styleName, “Presentation_Manager”) ==0) { guiFactory = new PMFactory; } else …

48. Supporting Multiple Look-and-Feel Standards • Abstract Object Creation with Factories • One class is responsible for creating objects • Set standard and then all objects are created with that standard • Abstract Factory Pattern • Provides interface for creating families of related or dependent objects without specifying concrete classes • Swap entire families of products by replacing the concrete factory • Singleton • Ensure a class has only on instance • Provide global point of access

49. Supporting Multiple Windows Systems • Can we use an Abstract Factory? • Unlikely interface for different vendors are compatible thus don’t have common abstract product class Remember we could only apply Abstract factory where we could define a common abstract product (e.g. Button widget) from which we could subclass concrete products (MotifButton, PMButton,MacButton)

50. Supporting Multiple Windows Systems • Things are a bit tougher since different windowing systems do not provide compatible interfaces • 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