1Design Patterns for OODevelopment2Course Objectives• History and the relevance of design patterns• Detailed coverage of some popular existingpatterns– a simple example: The Proxy pattern– case study3The Proxy Pattern• Context:– situations in which access to an object should bedeferred• In graphical application, protect objects whose display isexpensive or slow (e.g., a picture)• In network application, facilitate access to distributed objects(e.g., make it easy for a client to find a server)• In OS application, protect objects from unauthorized access4The Proxy Pattern (cont’d)• Problem:– Prevent an object from being accessed directly by itsclients• Solution:– Use an additional object, called a proxy– Client accesses protected object only through proxy– Proxy keeps track of status and/or location of protectedobject5RealSubjectRequest()Subject Request() ...if (statusOK) realSubject->request(); else {…};ProxyRequest() statusrealSubjectClass Diagram6aClientsubjectaProxyrealSubjectaRealSubjectObject Diagram7Components of a Pattern• Pattern name– identify this pattern; distinguish from other patterns– define a lexicon for OO design• Pattern alias - also known as• Real-world example• Context• Problem8Components of a Pattern (cont’d)• Solution– typically natural language notation• Structure– class (and possibly object) diagram in solution• Interaction diagram• Consequences– advantages and disadvantages of pattern– ways to address residual design decisions9Components of a Pattern (cont’d)• Implementation– critical portion of plausible code for pattern• Known uses– often systems that inspired pattern• References - See also– related patterns that may be applied in similar cases10Taxonomy of Patterns• Three kinds of patterns, based on purpose:– creational patterns• describe how to create objects• often by delegation of responsibility from an abstract class toconcrete subclasses– structural patterns• describe how to define structures and their relationships– behavioral patterns• describe object behavior and interactions among objects11Principles Underlying Patterns• Rely on abstract classes to hide differencesbetween subclasses from clients– object class vs. object type• class defines how an object is implemented• type defines an object’s interface (protocol)• Program to an interface, not an implementation12Principles (cont’d)• Black-box vs. white-box reuse– black-box relies on object references, usually throughinstance variables– white-box reuse by inheritance– black-box reuse preferred for information hiding, run-time flexibility, elimination of implementationdependencies– disadvantages: Run-time efficiency (high number ofinstances, and communication by message passing)• Favor composition over class inheritance13Principles (cont’d)• Delegation– powerful technique when coupled with black-box reuse– Allow delegation to different instances at run-time, aslong as instances respond to similar messages– disadvantages:• sometimes code harder to read and understand• efficiency (because of black-box reuse)14Lexi: A Simple GUI-Based Editor• Lexi is a WYSIWYG editor– supports documents with textual and graphical objects– scroll bars to select portions of the document– be easy to port to another platform– support multiple look-and-feel interfaces• Highlights several OO design issues• Case study of design patterns in the design of Lexi15Design Issues• Representation and manipulation of document• Formatting a document• Adding scroll bars and borders to Lexi windows• Support multiple look-and-feel standards• Handle multiple windowing systems• Support user operations• Advanced features– spell-checking and hyphenation16Structure of a Lexi Document• Goals:– store text and graphics in document– generate visual display– maintain info about location of display elements• Caveats:– treat different objects uniformly• e.g., text, pictures, graphics– treat individual objects and groups of objects uniformly• e.g., characters and lines of text17Structure of a Lexi Document• Solution:– define abstract class Glyph for all displayed objects– glyph responsibilities:• know how to draw itself• knows what space it occupies• knows its children and parent– use recursive composition for defining and handlingcomplex objects– define composition of Glyph as instances of Glyph18...Rectangle...Glyph Draw(window)Intersect(point) Insert(Glyph*,int)Character...Polygon...Row...Glyph Class Diagram19The Composite Pattern• Motivation:– support recursive composition in such a way that aclient need not know the difference between a singleand a composite object (as with Glyphs)• Applicability:– when dealing with hierarchically-organized objects(e.g., columns containing rows containing words …)• Structure: Same as previous picture20Composite Pattern (cont’d)• Consequences:– class hierarchy has simple and composite objects– simplify clients– extensibility• clients do not have to be modified– too general a pattern?• difficult to to restrict functionality of concrete leaf subclasses21Composite Pattern (cont’d)• Implementation Issues:– parent references• facilitate traversal of hierarchy– sharing components• save space, but at the price of increased programmingcomplexity (e.g., difficult to implement with a single parentpointer)22Composite Pattern (cont’d)– overgenerality• how do components avoid defining methods that don’t makesense for some leafs?• especially methods that make sense only for composites, e.g.,format, group, ungroup?• possibly view leafs as components with no children– where do you define child management methods?• In root: transparent, but leafs may do silly things• In composites: safer because leafs do not respond to method,but loss of uniformity23Composite Pattern (cont’d)– should components implement list of components?• e.g., as an instance variable?• probably yes, except that leafs would never use this variable– child ordering• sometimes an issue (e.g., a row of Lexi text)– caching to improve performance• save I/O data to avoid recomputation– who should delete components?• probably the responsibility of the composite24Formatting Lexi Documents• Handle justification, margins, line breaking, etc.• Many good algorithms exist;– different
View Full Document