Design Patterns A Case Study Designing a Document



































- Slides: 35
Design Patterns A Case Study: Designing a Document Editor 9/4/2021 Peter Cappello cappello@cs. ucsb. edu
cappello@cs. ucsb. edu 9/4/2021 Attributions l This material is based on the 2 nd Chapter of: Design Patterns, by Gamma, Helm, Johnson, & Vlissides. l 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.
cappello@cs. ucsb. edu 9/4/2021 Introduction l OOD l The of a WYSIWYG document editor: – can mix text & graphics – has a GUI (see next slide)
Lexi 9/4/2021 File Edit Style Symbol Fig. 4 A gratuitous graphic Here is some gratuitous text to indicate the text formatting capabilities - + 1 2 3 4 cappello@cs. ucsb. edu
cappello@cs. ucsb. edu 9/4/2021 Design Problems l Document Representation l Formatting l Embellishing the UI l Support multiple look-&-feel standards l Support multiple window systems l User operations l Spelling checking & hyphenation
cappello@cs. ucsb. edu 9/4/2021 Design Problems l Document Representation – The document’s representation affects: • editing, formatting, displaying, & analysis – e. g. , hyphenation – Physical vs. logical representation l Formatting – How to arrange boxes into lines, columns, pages? – What objects implement formatting policies? – How do these interact with representation?
cappello@cs. ucsb. edu 9/4/2021 Design Problems. . . l Embellishing the UI – GUI changes are likely. – Add/remove/modify GUI elements should be easy. l Support multiple look-&-feel standards – Implement with Swing (what if no swing? ) l Support multiple window systems – Implement with Swing (what if no swing? )
cappello@cs. ucsb. edu 9/4/2021 Design Problems. . . l User operations – Users control model via GUI. – Functions are distributed among many objects. – Access these functions in a uniform way • undo. l Spelling checking & hyphenation – How does Lexi support analytical operations? – Minimize # of classes affected by such operations • Reduce cost of enhancements
cappello@cs. ucsb. edu 9/4/2021 Design Problems l Document Representation l Formatting l Embellishing the UI l Support multiple look-&-feel standards l Support multiple window systems l User operations l Spelling checking & hyphenation
cappello@cs. ucsb. edu 9/4/2021 Document Representation Outline l Goals l Constraints l Recursive Composition l Glyphs l Composite Pattern
cappello@cs. ucsb. edu 9/4/2021 Document Representation Goals l User views document as a: – logical structure – physical structure. l User composes & interacts with substructures – E. g. , sections, tables, lines, figures – Representation matches physical structure. • Could have representation reflect logical structure.
cappello@cs. ucsb. edu 9/4/2021 Document Representation Goals Representation helps: l Maintain document’s physical structure – lines, columns, tables, etc. l Generating l Map a view pixel positions to internal elements – So Lexi can track mouse clicks, etc.
cappello@cs. ucsb. edu 9/4/2021 Document Representation Outline l Goals l Constraints l Recursive Composition l Glyphs l Composite Pattern
cappello@cs. ucsb. edu 9/4/2021 Document Representation Constraints l Treat text & graphics uniformly – graphics within text – text within graphics – format “elements” an abstraction of both l Anywhere 1 element may go, so may a group go. – Allows arbitrarily complex documents l Support operations that violate these constraints – spelling , hyphenation
cappello@cs. ucsb. edu 9/4/2021 Document Representation Outline l Goals l Constraints l Recursive Composition l Glyphs l Composite Pattern
cappello@cs. ucsb. edu 9/4/2021 Recursive Composition l Recursive composition: construct complex objects from simpler ones of the same abstract type. l 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. l Graphics are boxes similar to characters.
cappello@cs. ucsb. edu 9/4/2021 Composite (column) characters G g space image Composite (row)
cappello@cs. ucsb. edu 9/4/2021 Object Structure for Recursive Composition of Text & Graphics Composite (column) Composite (row) G g space Composite (row)
cappello@cs. ucsb. edu 9/4/2021 Recursive Composition. . . l An object for each character & graphic promotes: – flexibility – uniformity • displaying, formatting, embedding – ease of adding new “character” sets l Object structure reflects physical structure l Objects’ classes extend abstract class: inheritance.
cappello@cs. ucsb. edu 9/4/2021 Document Representation Outline l Goals l Constraints l Recursive Composition l Glyphs l Composite Pattern
cappello@cs. ucsb. edu 9/4/2021 Glyphs l Glyph: the name of the abstract class for document objects. l. A glyph is responsible to know: – how to draw itself – what space it occupies – who its children [& parent] are
cappello@cs. ucsb. edu 9/4/2021 Glyphs: Responsibility & Methods l Appearance – void draw(Window w) – Rectangle bounds() l Hit Detection – boolean intersection(Point p) l 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
cappello@cs. ucsb. edu 9/4/2021 Partial Glyph Class Hierarchy Glyph draw(Window) intersects(Point) insert(Glyph, int). . . Character draw(Window) intersects(Point) char c Rectangle draw(. . . ) intersects(. . . ) Polygon draw(. . . ) intersects(. . . ) children Row draw(. . . ) intersects(. . . ) insert(Glyph, int)
cappello@cs. ucsb. edu 9/4/2021 Glyphs. . . l Extensions of Glyph implement its methods – Rectangle implements draw: void draw(Window w) { w. draw. Rect(x, y, width, height); } where: • x, y, width, & height are Rectangle data members indicating its position • Window extends Graphic
cappello@cs. ucsb. edu 9/4/2021 Document Representation Outline l Goals l Constraints l Recursive Composition l Glyphs l Composite Pattern
cappello@cs. ucsb. edu 9/4/2021 Composite Pattern l Intent – Compose objects into hierarchies: child part-of parent l Motivation – Clients treat objects & their compositions uniformly – Uses abstract class to represent both: • primitive object • container object • Declares common methods (e. g. , draw)
cappello@cs. ucsb. edu 9/4/2021 Composite Pattern Structure Component Client operation() add(Component) remove(Component) get. Child(int) Leaf operation() Composite operation() add(Component) remove(Component) get. Child(int) children
cappello@cs. ucsb. edu 9/4/2021 Composite Pattern Participants l Component – declares interface for • objects • accessing & managing children • accessing parent – implements default behavior l Leaf – represents primitive objects – has 0 children
9/4/2021 cappello@cs. ucsb. edu Composite Pattern Participants. . . l Composite – defines behavior for containers – contains children – implements child-related operations of Component interface l Client – manipulates objects polymorphically via Component interface.
cappello@cs. ucsb. edu 9/4/2021 Composite Pattern Collaborations l Client accesses objects via Component interface l If object is primitive, handle requests directly else recursively request operation of its children
9/4/2021 cappello@cs. ucsb. edu Composite Pattern Consequences l Enables client to access objects polymorphically: – primitive – composite l Facilitates adding new concrete classes: – primitive – container l Disadvantage – If a container class can contain only certain types of components, it cannot be restricted by type system. – Partition Composite class?
9/4/2021 cappello@cs. ucsb. edu Composite Pattern Implementation l There are many implementation issues: – Explicit parent references • simplify traversal – Maximizing the Component interface – Where are child management operations declared? – Caching to improve performance l See Design Patterns to get a feel for them.
cappello@cs. ucsb. edu 9/4/2021 When Use a Composite Pattern? l Good candidate for any structure that is: – recursive – hierarchical
cappello@cs. ucsb. edu 9/4/2021 Design Problems l Document Representation l Formatting l Embellishing the UI l Support multiple look-&-feel standards l Support multiple window systems l User operations l Spelling checking & hyphenation
cappello@cs. ucsb. edu 9/4/2021 Formatting Outline l Encapsulating l Compositor l Strategy the Formatting Algorithm & Composition Pattern