Design Patterns A Case Study: Designing a Document Editor

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