Chapter 2: Case Study

1
Chapter 2 Case Study

• Designing a Document Editor

2
Lexi Design Issues

• Document Structure
• Formatting
• Embellishing the UI
• Supporting multiple look feel standards
• Supporting multiple window systems

3
Document Structure

• We have 3 main goals
• Maintain a physical structure that envelopes all
  components of the document
• Let the user see the document
• Map all parts of the visual document, through the
  UI, to the physical document

4
Maintain Physical Structure

• Design Issues
• Encompassing information not only to individual
  characters, but also to lines, words, and graphic
  components
• Treating all components of the document equally.
  
• Treating each component differently, based on
  need.
• And hereby it shall be written, that all
  characters, lines, and graphical representations
  shall be equal, with liberty and spell checking
  for all. Some Famous Guy Im sure

5
Recursive Composition

• Build complex elements out of simpler ones
• A few characters in a row form a line
• A few lines form a column
• A few columns form a page
• etc.

6
Recursive Composition Consequences

• Benefits
• Flexibility among all levels of design
• Extension of current design is no problem
• Constraints
• Each object needs a class
• All classes need compatible interfaces

7
Class Breakdown

• Glyph
• Base class for all document types
• Know How to Draw
• Know Where they are
• Know Parent and Child related to them
• A glyph can be a Row, a Line, a graphic, or a
  character

8
Glyphs

• Drawbacks
• Strict Hierarchy
• Efficiency
• Potentially fixed by Flyweight pattern
• Each Glyph has a context, whether its a row,
  line, or character
• Promotes reduced memory storage due to intrinsic
  and extrinsic states being in separate objects.
  Intrinsic is stored in the flyweight object (and
  can be shared), while extrinsic depends on the
  context and cant be shared.

9
Formatting

• Constructing a physical structure
• Formatting algorithms need to
• Remain independent of document structure
• Be variable so we can build for speed or quality

10
Formatting Algorithms

• Design Patterns
• Composite
• Compositor class to
• Know what glyphs to format
• When to format
• Composition class, which is a special Glyph class
  to
• Let the compositor know when to compose itself
• Composite allows us to keep the algorithm and
  glyph functionality separate
• Strategy
• Allows us to switch out algorithms to different
  Glyphs

11
Embellishing the UI

• Adding a Border / Adding a scroll bar
• Goal To add/remove these functionalities easily
• Issue Inheritance will cause explosion of
  classes
• Issue How to make glyphs aware of UI
  embellishments
• Best if other UI objects dont know about the
  embellishment

12
Embellishment Design Patterns

• Inheritance will fail
• Too many combinations of embellishment (scroll
  bar, borders, scroll bar borders)
• Code explodes to drastic measures the more
  embellishments we add, making it unmanageable.
• Object Composition
• Make each embellishment an object, for instance,
  Border.
• Border could contain Glyph, or Glyph could
  contain Border.
• Possible drawbacks of each approach

13
Borders

• What should they look like?
• Should be treated like a Glyph, since the client
  just sees a border as another part of the
  Document.
• Transparent Enclosure
• Combines both single-component composition, and
  compatible interfaces
• This gives us the design we need to treat
  embellishments just like everything else in the
  Document structure
• MonoGlyph
• Essentially a Decorator Pattern
• Holds reference(s) to an object(s) which it
  passes all commands to
• Hides the class structures it has references to
• Allows embellishments to interact with each
  other, and yet separating out that functionality
  from a regular Glyph.

14
Decorator Pattern

• Lets us add responsibilities to an object
• Masks interface to hide extra embellishments
• Forwards requests to embellishments
• Can do them in whatever order they choose.

15
Supporting Multiple Look-and-Feel Standards

• Operability across several platforms
• Adding new platforms easily
• Widget Glyph classes solution
• Abstract Glyph subclasses for each widget.
• an abstract class ScrollBar will augment the
  basic glyph interface to add general scrolling
  operations
• Concrete subclasses for each Abstract glyph
  subclass.
• ScrollBar might have MotifScrollBar and
  PMScrollBar
• One problem maintaining multiple construction
  objects

16
Abstract the process of object creation

• Factories and Product Classes
• We add in MotifScrollBar functionality into a
  GUIFactory that abstracts away any reference to
  Motif.
• Do this for all Look-and-Feel objects
• Abstract Factory Pattern
• Allows us to create Families of objects without
  instantiating any classes directly.
• This would involve creating any look-and-feel
  objects.
• Singleton
• Create a single GUIFactory that will have
  references to Motif and other such look-and-feel
  objects
• Then is instantiated with a Motif or
  presentation manager as input, so it knows what
  it has to create
• Provides a single object (and no more!) that has
  global access

17
Supporting Multiple Window Systems

• Different Platforms
• Different windowing systems
• Different keyboard/mouse inputs
• Should we use Abstract Factory again?
• No, since UI from common vendors are likely
  incompatible
• So we dont have a common abstract product class
• Encapsulating Implementation Dependencies
• Basic requirements
• Draw shapes
• Iconify and de-iconify themselves
• Resize themselves
• Redraw the contents on demand

18
Window Class Functionality

• Intersection of functionality
• Providing functionality that is common over all
  windowing systems
• Union of Functionality
• Create an interface that supports all
  functionality of all window systems
• Neither approach is optimal, as they involve
  either too little functionality or too much
  coding.
• Secret option 3.

19
Encapsulate the concept that varies

• Window
• Abstract base class that has an interface to
• ApplicationWindow
• DialogWindow
• IconWindow
• (i.e. 3 mainstream Windows that are implemented)
• WindowIMP
• Has an implementation for each platform (Mac, X,
  etc.)
• This doesnt clutter our dependencies, so the
  Window class is fairly small and stable

20
Bridge Pattern

• Goal decouple abstraction from implementation
• We achieve this through Window and WindowIMP.
• WindowIMP is something application developers
  will never see, they will only work with Window,
  making their lives easier.