GoF: Document Editor Example Rebecca Miller-Webster

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

Design Problems Document Structure –Internal structure; need to traverse Formatting –Arrange text 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 Support multiple look-and-feel Support multiple window systems

Design Problems For Next Time: User Operations –Buttons, pull-down menus Spelling checking and hyphenation

Document Structure Arrangement of graphical elements Users need to treat collection and single elements the same (line vs. table) –Composite Pattern! Internal Representation –Maintain physical structure, present visually, map display and physical structures

Document Structure Use recursive composition Glyphs: abstract class –Primitive graphical elements –Structural elements –Responsibilities: Draw themselves Where they are Children and parent

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

Formatting Know how to represent physical structure Need to construct particular structure Formatting: breaking collection of glyphs into lines Trade-offs: quality, speed, space

Formatting Encapsulate Format algorithm –Compositor: formatting algorithm What glyphs to format and when to do formatting –Composition: special glyph class Gets Compositor (specific algorithm) when created and tells compositor to compose its glyphs Compositor-Composition ensures separation between physical representation and formatting Strategy Pattern –Objects encapsulate algorithms and the context in which they operate –Must design interface to support range of algorithms

Embellishing the User Interface Border and Scrollbar Easily add and remove –No inheritance (run-time, lots of classes) –Object composition (embellishment is object) Border contain Glyph? Glyph contain Border? (modify glyph class to be aware of border)

Embellishing the User Interface Transparent enclosure –1) single child/component composition –2) compatible interfaces MonoGlyph (subclass of glyph) –Stores reference to a component (glyph) and forwards requests to it –Performs embellishment before or after sending glyph the request (draw itself)

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 Support for current and future 2 sets of classes: –Set of abstract glyph subclass for each widget category –Set of concrete subclasses to implement different standards

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 Singleton –Ensure a class has only on instance –Provide global point of access

Supporting Multiple Windows Systems Abstract Factory? –Unlikely interface for different vendors are compatible thus don’t have common abstract product class –Encapsulate Implementation Dependencies Window Class: general actions –Draw geometric shapes –Iconifiy and de-iconify themselves –Resize self –Redraw contents on demand

Supporting Multiple Windows Systems Intersection or union of functionality? One version of Windows and subclasses for each Windows platform? Implementation specific subclasses of Window class? OR …

Supporting Multiple Windows Systems Encapsulate the concept that varies WindowImp class: abstract class for objects that encapsulate system-dependent code Configure window object with instance of WindowImp Bridge Pattern: –Decouple abstraction from implementation

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