GoF: 2.1-2.6 Document Editor Example A Case Study

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.

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

Design Problems Document Structure Formatting 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

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

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

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.

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)

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

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

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

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.

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

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.

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

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

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.

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

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

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

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

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

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

Formatting Encapsulating Format algorithm Compositor: class for formatting algorithm objects What glyphs to format and when to do the formatting Responsibility Operation What to format Void SetComposition(Composition *) When to format Virtual void Compose()

Formatting

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

Formatting

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.

Formatting column row row

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

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.

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.

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

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

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

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

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 MonoGlyph to 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)

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);}

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.

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

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

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

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

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

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

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.

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)

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

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 …

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

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)

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

Supporting Multiple Windows Systems Encapsulating Implementation Dependencies Window Class: general actions Draw basic geometric shapes Iconifiy and de-iconify themselves Resize self Redraw contents on demand

Supporting Multiple Windows Systems The Two extreme: Intersection of functionalities? Trouble: We loose a lot of functionalities or union of functionality? Trouble: the resulting interface maybe huge and incoherent. We also have to revise the code for every new vendor

Supporting Multiple Windows Systems The solution falls somewhere between the two. The Window class would have interfaces that support the most popular windowing features. Table 2.3 provides a sample.

Supporting Multiple Windows Systems The concrete subclasses of our Window class support different kinds (not platform) of windows such as dialogWindow, warningWindow, applicationWindow, etc

Supporting Multiple Windows Systems Now where does platform-specific window come in? One approach: Implement one version of our Window class and subclasses for each Windowing platform? Imagine the maintenance headache to keep track of multiple classes all named “Window” but each implemented for a different windowing system

Supporting Multiple Windows Systems Another approach: Implementation specific subclasses of Window class? And end up with another subclass explosion In addition, none of these approaches give the flexibility to change the window system after compile. So we need to keep several different executables. So, what can we do?

Supporting Multiple Windows Systems Encapsulate the concept that varies (window system implementation in this case) WindowImp class: abstract class for objects that encapsulate system-dependent code Configure window object with instance of WindowImp subclasses

Supporting Multiple Windows Systems

Supporting Multiple Windows Systems Bridge Pattern: Decouple abstraction from implementation The relationship between Window and WindowImp is an example of Bridge pattern The intent is to allow separate class hierarchies work together even as they evolve independently.

Take Away You’re not a fortune teller Decoupling/Independence Internal/external, abstraction/implementation Use patterns appropriately: Inheritance vs. object composition (user interface) Abstract Factory vs. Encapsulate Dependencies (Window) Transparency Focus on the concept that varies