1. Design a Document Editor Oksana Protsyk Yaroslav Kaplunskiy

2. Task is… Design a "What-You-See-Is-What-You- Get" (or "WYSIWYG") document editor called Lexi. On Lexi’s example see how to use design patterns

3. Design problems Document structure. Formatting. Embellishing the user interface. Supporting multiple look-and-feel standards. Supporting multiple window systems.. User operations. Spelling checking and hyphenation.

4. Document Structure A document is an arrangement of characters, lines, polygons, and other shapes. Yet an author often views these elements not in graphical terms but in terms of the document's physical structure—lines, columns, figures, tables, and other substructures. Lexi's user interface should let users manipulate these substructures directly. Besides, - we should treat text and graphics uniformly. - our implementation shouldn't have to distinguish between single elements and groups of elements in the internal representation

5. Internal representation 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. Recursive Composition Objects can be composited recursively with the use of recursive types or references. Consider a tree. Each node in a tree may be a branch or leaf; in other words, each node is a tree at the same time when it belongs to another tree.

7. Recursive Composition

8. The objects need corresponding classes these classes must have compatible interfaces, because we want to treat the objects uniformly

9. Glyphs

10. Class Glyph{ virtual void Draw(Window* ); virtual void Bounds(Rect&); virtual bool Intersects(const Point&); virtual void Insert(Glyph*, int); virtual void Remove(Glyph*); virtual Glyph* Child(int); virtual Glyph* Parent(); };

11. The Window class defines graphics operations for rendering text and basic shapes in a window on the screen. A Rectangle subclass of Glyph might redefine Draw as follows: void Rectangle::Draw (Window* w) { w->DrawRect(_x0, _y0, _x1, _y1); }

12. 1. Composite Pattern

13. Formatting Representation and formatting are distinct: The ability to capture the document's physical structure doesn't tell us how to arrive at a particular structure. How to construct a particular physical structure?

14. Formatting the user might want to vary margin widths, indentation, and tabulation; single or double space; and probably many other formatting constraints. Lexi's formatting algorithm must take all of these into account we'll restrict "formatting" to mean breaking a collection of glyphs into lines

15. Formatting balance between formatting quality and formatting speed Because formatting algorithms tend to be complex, it's desirable to keep them well- contained or—better yet—completely independent of the document structure add a new Glyphs subclass without regard to the formatting add a new formatting algorithm shouldn't require modifying existing glyphs.

16. Compositor and Composition

17. Formatting Class Compositor{ //what to format void SetComposition (Composition*); //when to format virtual void Compose(); };

18. Formatting

19. We can add new Compositor subclasses without touching the glyph classes, and vice versa In fact, we can change the line breaking algorithm at run-time by adding a single SetCompositor operation to Composition's basic glyph interface

20. 2. Strategy Pattern

21. Embellishing the User Interface 1) add a border around the text editing area to demarcate the page of text. 2) add scroll bars that let the user view different parts of the page. Should we use inheritance?

22. Or add a border to Composition by subclassing it to yield a BorderedComposition class, and scrolling interface to a ScrollableComposition?

23. Object composition offers a potentially more workable and flexible extension mechanism. But what objects do we compose? class Border is Glyph’s subclass

24. Transparent enclosure combines the notions of (single-child (or single-component) composition and (2) Compatible interfaces

25. MonoGlyph

26. Monoglyph void MonoGlyph::Draw (Window* w) { _component->Draw(w); } void Border::Draw (Window* w) { MonoGlyph::Draw(w); DrawBorder(w); }

27. 3. Decorator Pattern

28. Supporting Multiple Look- and-Feel Standards Achieving portability across hardware and software platforms is a major problem in system design The invisible glyphs compose visible ones like Button and Character and lay them out properly

29. Look-and-Feel Standards A set of abstract Glyph subclasses for each category of widget glyph A set of concrete subclasses for each abstract subclass that implement different look-and- feel standards ScrollBar* sb = guiFactory->CreateScrollBar();

32. 4. Abstract Factory Pattern

33. Supporting Multiple Window Systems Can We Use an Abstract Factory?

34. In applying the Abstract Factory pattern, we assumed we would define the concrete widget glyph classes for each look-and-feel standard. That meant we could derive each concrete product for a particular standard from an abstract product class.

36. class Window Intersection of functionality The Window class interface provides only functionality that's common to all window systems Union of functionality. Create an interface that incorporates the capabilities of all existing systems

37. class Window //window management virtual void Redraw(); virtual void Raise(); virtual void Lower(); virtual void Iconify(); virtual void Deiconify(); //graphics virtual void DrawLine(...); virtual void DrawRect(...); virtual void DrawPolygon(...) virtual void DrawText(...)

39. Window

40. how a window gets configured withthe proper WindowImp subclass in the first place?

41. class WindowSystemFactory { public: virtual WindowImp* CreateWindowImp() = 0; virtual ColorImp* CreateColorImp() = 0; virtual FontImp* CreateFontImp() = 0; // a "Create..." operation for all window //system resources }; //for concrete class PMWindowSystemFactory : public WindowSystemFactory { virtual WindowImp* CreateWindowImp() { return new PMWindowImp; } };

42. 5. Bridge Pattern

43. User Operations creating a new document, opening, saving, and printing an existing document, cutting selected text out of the document and pasting it back in, changing the font and style of selected text, changing the formatting of text, such as its alignment andjustification, quitting the application, and on and on.

44. Problems we don't want to associate a particular user operation with a particular user interface these operations are implemented in many different classes we want Lexi to support undo andredo8ofmost but not all its functionality

46. We also add Unexecute() to Command interface

47. Command History

49. 6. Command Pattern

50. Spelling Checking and Hyphenation Accessing Scattered Information access mechanism must accommodate differing data structures Encapsulating Access and Traversal void First(Traversal kind); void Next(); bool IsDone(); Glyph* GetCurrent(); void Insert(Glyph*);

52. 7. Iterator Pattern

53. Traversal versus Traversal Actions analysis and traversal should be separate each analysis we can add one or more abstract operations to the Glyph class and have subclasses implement them in accordance with the role they play in the analysis but…

54. we'll have to change every glyph class whenever we add a new kind of analysis

55. class SpellingChecker { public: SpellingChecker(); virtual void CheckCharacter(Character*); virtual void CheckRow(Row*); virtual void CheckImage(Image*); //... and so forth List & GetMisspellings(); protected: virtual bool IsMisspelled(const char*); private: char _currentWord[MAX_WORD_SIZE]; List _misspellings; };

57. class Visitor { public: virtual void VisitCharacter(Character*) { } virtual void VisitRow(Row*) { } virtual void VisitImage(Image*) { } //... and so forth };

58. 8. Visitor Pattern

59. Summary We've applied eight different patterns to Lexi's design: 1. Composite to represent the document's physical structure, 2. Strategy to allow different formatting algorithms, 3. Decorator for embellishing the user interface, 4. Abstract Factory for supporting multiple look-and-feel standards, 5. Bridge to allow multiple windowing platforms, 6. Command for undoable user operations, 7. Iterator for accessing and traversing object structures, and 8. Visitor for allowing an open-ended number of analytical capabilities without complicating the document structure's implementation.

60. Literature Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides Design Patterns Explained Simply http://sourcemaking.com/design_patterns http://sourcemaking.com/design_patterns

61. Дякую за увагу