1 / 19

GoF: 2.1-2.6 Document Editor Example

GoF: 2.1-2.6 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

iliana
Download Presentation

GoF: 2.1-2.6 Document Editor Example

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

More Related