DOC PREVIEW
UMD CMSC 433 - Design Patterns for OO Development

This preview shows page 1-2-3-4 out of 13 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 13 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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

UMD CMSC 433 - Design Patterns for OO Development

Documents in this Course
Trace 1

Trace 1

62 pages

Reflection

Reflection

137 pages

Testing

Testing

25 pages

Paradigms

Paradigms

10 pages

Testing

Testing

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Java RMI

Java RMI

17 pages

Trace 1

Trace 1

46 pages

Jini

Jini

4 pages

Final

Final

15 pages

Java RMI

Java RMI

13 pages

Testing

Testing

16 pages

Load more
Download Design Patterns for OO Development
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Design Patterns for OO Development and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Design Patterns for OO Development 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?