Chapter 2 Case Study Designing a Document Editor

Chapter 2: Case Study Designing a Document Editor

Lexi Design Issues • • • Document Structure Formatting Embellishing the UI Supporting multiple look & feel standards Supporting multiple window systems

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

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 I’m sure

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.

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

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

Glyphs • Drawbacks – Strict Hierarchy – Efficiency • Potentially fixed by Flyweight pattern – Each Glyph has a context, whether it’s 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 can’t be shared.

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

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

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 don’t know about the embellishment

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

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 • Mono. Glyph – – 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.

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.

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 Scroll. Bar will augment the basic glyph interface to add general scrolling operations” – Concrete subclasses for each Abstract glyph subclass. • “Scroll. Bar might have Motif. Scroll. Bar and PMScroll. Bar” – One problem: maintaining multiple construction objects

“Abstract the process of object creation” • Factories and Product Classes – We add in Motif. Scroll. Bar 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-andfeel 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

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 don’t 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

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

Encapsulate the concept that varies • Window – Abstract base class that has an interface to • • Application. Window Dialog. Window Icon. Window (i. e. 3 mainstream Windows that are implemented) • Window. IMP – Has an implementation for each platform (Mac, X, etc. ) – This doesn’t clutter our dependencies, so the Window class is fairly small and stable

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