1 / 35

Design Patterns A Case Study: Designing a Document Editor

Design Patterns A Case Study: Designing a Document Editor. Attributions. This material is based on the 2nd Chapter of: Design Patterns , by Gamma, Helm, Johnson, & Vlissides. The chapter, in turn, is based on:

lgalbraith
Download Presentation

Design Patterns A Case Study: Designing a Document Editor

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. Design PatternsA Case Study:Designing a Document Editor Peter Cappello

  2. Attributions • This material is based on the 2nd Chapter of: Design Patterns,by Gamma, Helm, Johnson, & Vlissides. • The chapter, in turn, is based on: Paul R. Calder & Mark A. Linton. The object-oriented implementation of a document editor. In Object-Oriented Programming Systems, Languages, & Applications Conference Proceedings, p. 154-165, Vancouver, Oct. 1992. ACM Press.

  3. Introduction • OOD of a WYSIWYG document editor • The editor: • can mix text & graphics • has a GUI (see next slide)

  4. Lexi File Edit Style Symbol WYSIWYG Editor Fig. 4 A gratuitous graphic Here is some gratuitous text to indicate the text formatting capabilities - + 1 2 3 4

  5. Design Problems • Document Representation • Formatting • Embellishing the UI • Support multiple look-&-feel standards • Support multiple window systems • User operations • Spelling checking & hyphenation

  6. Design Problems • Document Representation • The document’s representation affects: • editing, formatting, displaying, & analysis • e.g., hyphenation • Physical vs. logical representation • Formatting • How to arrange boxes into lines, columns, pages? • What objects implement formatting policies? • How do these interact with representation?

  7. Design Problems ... • Embellishing the UI • GUI changes are likely. • Add/remove/modify GUI elements should be easy. • Support multiple look-&-feel standards • Implement with Swing (what if no swing?) • Support multiple window systems • Implement with Swing (what if no swing?)

  8. Design Problems ... • User operations • Users control model via GUI. • Functions are distributed among many objects. • Access these functions in a uniform way • undo. • Spelling checking & hyphenation • How does Lexi support analytical operations? • Minimize # of classes affected by such operations • Reduce cost of enhancements

  9. Design Problems • Document Representation • Formatting • Embellishing the UI • Support multiple look-&-feel standards • Support multiple window systems • User operations • Spelling checking & hyphenation

  10. Document Representation Outline • Goals • Constraints • Recursive Composition • Glyphs • Composite Pattern

  11. Document RepresentationGoals • User views document as a: • logical structure • physical structure. • User composes & interacts with substructures • E.g., sections, tables, lines, figures • Representation matches physical structure. • Could have representation reflect logical structure.

  12. Document RepresentationGoals Representation helps: • Maintain document’s physical structure • lines, columns, tables, etc. • Generating a view • Map pixel positions to internal elements • So Lexi can track mouse clicks, etc.

  13. Document Representation Outline • Goals • Constraints • Recursive Composition • Glyphs • Composite Pattern

  14. Document RepresentationConstraints • Treat text & graphics uniformly • graphics within text • text within graphics • format “elements” an abstraction of both • Anywhere 1 element may go, so may a group go. • Allows arbitrarily complex documents • Support operations that violate these constraints • spelling , hyphenation

  15. Document Representation Outline • Goals • Constraints • Recursive Composition • Glyphs • Composite Pattern

  16. Recursive Composition • Recursive composition: construct complex objects from simpler ones of the sameabstract type. • For example, consider streams: • streams of characters are broken into lines • streams of lines are broken into columns • streams of columns are broken into pages. • Graphics are boxes similar to characters.

  17. Composite (column) Composite (row) characters space image G g

  18. Object Structure for Recursive Composition of Text & Graphics Composite (column) Composite (row) Composite (row) G g space

  19. Recursive Composition ... • An object for each character & graphic promotes: • flexibility • uniformity • displaying, formatting, embedding • ease of adding new “character” sets • Object structure reflects physical structure • Objects’ classes extend abstract class: inheritance.

  20. Document Representation Outline • Goals • Constraints • Recursive Composition • Glyphs • Composite Pattern

  21. Glyphs • Glyph: the name of the abstract class for document objects. • A glyph is responsible to know: • howto draw itself • what space it occupies • who its children[& parent] are

  22. Glyphs: Responsibility & Methods • Appearance • void draw(Window w) • Rectangle bounds() • Hit Detection • boolean intersection(Point p) • Structure • void insert(Glyph g, int i) // why is i used? • void remove(Glyph g) // why an argument? • Glyph child(int i) // return child at i • Glyph parent() // return parent glyph

  23. Partial Glyph Class Hierarchy Glyph draw(Window) intersects(Point) children insert(Glyph, int) . . . Character Rectangle Polygon Row draw(Window) draw(...) draw(...) draw(...) intersects(Point) intersects(...) intersects(...) intersects(...) insert(Glyph, int) char c

  24. Glyphs ... • Extensions of Glyph implement its methods • Rectangle implements draw: void draw(Window w) { w.drawRect(x, y, width, height); } where: • x, y, width, & height are Rectangle data members indicating its position • Window extends Graphic

  25. Document Representation Outline • Goals • Constraints • Recursive Composition • Glyphs • Composite Pattern

  26. Composite Pattern • Intent • Compose objects into hierarchies: child part-of parent • Motivation • Clients treat objects & their compositions uniformly • Uses abstract class to represent both: • primitive object • container object • Declares common methods (e.g., draw)

  27. Composite Pattern Structure Component Client operation() children add(Component) remove(Component) getChild(int) Leaf Composite operation() operation() add(Component) remove(Component) getChild(int)

  28. Composite Pattern Participants • Component • declares interface for • objects • accessing & managing children • accessing parent • implements default behavior • Leaf • represents primitive objects • has 0 children

  29. Composite Pattern Participants ... • Composite • defines behavior for containers • contains children • implements child-related operations of Component interface • Client • manipulates objects polymorphically via Component interface.

  30. Composite Pattern Collaborations • Client accesses objects via Component interface • If object is primitive, handle requests directly else recursively request operation of its children

  31. Composite Pattern Consequences • Enables client to access objects polymorphically: • primitive • composite • Facilitates adding new concrete classes: • primitive • container • Disadvantage • If a container class can contain only certain types of components, it cannot be restricted by type system. • Partition Composite class?

  32. Composite Pattern Implementation • There are many implementation issues: • Explicit parent references • simplify traversal • Maximizing the Component interface • Where are child management operations declared? • Caching to improve performance • See Design Patterns to get a feel for them.

  33. When Use a Composite Pattern? • Good candidate for any structure that is: • recursive • hierarchical

  34. Design Problems • Document Representation • Formatting • Embellishing the UI • Support multiple look-&-feel standards • Support multiple window systems • User operations • Spelling checking & hyphenation

  35. Formatting Outline • Encapsulating the Formatting Algorithm • Compositor & Composition • Strategy Pattern

More Related