GoF: 2.1-2.6 Document Editor Example

1
GoF 2.1-2.6Document Editor Example

• Rebecca Miller-Webster

2
Document Editor

• What are your first thoughts about how to build a
  document editor?

• Internal structure
• Formatting
• Gui
• Spell Check

3
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

4
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

5
Design Problems

• For Next Time
• User Operations
• Buttons, pull-down menus
• Spelling checking and hyphenation

6
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

7
Document Structure

• Use recursive composition
• Glyphs abstract class
• Primitive graphical elements
• Structural elements
• Responsibilities
• Draw themselves
• Where they are
• Children and parent

8
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

9
Formatting

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

10
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

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

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

13
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

14
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

15
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

16
Supporting Multiple Windows Systems

• Abstract Factory?
• Unlikely interface for different vendors are
  compatible thus dont 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

17
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

18
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

19
Take Away

• Youre 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