DOC PREVIEW
UMD CMSC 433 - Design Patterns

This preview shows page 1-2-20-21 out of 21 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 21 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 21 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 21 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 21 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 21 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

23Design Patterns• Iterators are an example of a design pattern:– Design pattern = problem + solution in context– Iterators: solution for providing generic traversals• Design patterns capture software architectures anddesigns– Not direct code reuse!– Instead, solution/strategy reuse– Sometimes, interface reuse24Gang of Four• The book that started it all• Community refers toauthors as the “Gang ofFour”• Figures and some text inthese slides come frombook25Object Modeling Technique (OMT)• Used to describe patterns in GO4 book• Graphical representation of OO relationships– Class diagrams show the static relationship betweenclasses– Object diagrams represent the state of a program asseries of related objects– Interaction diagrams illustrate execution of theprogram as an interaction among related objects26Classes27Object instantiation28Subclassing and Abstract Classes29Pseudo-code and Containment30Object diagrams31Interaction diagramstime32Structure of Iterator (Cursor) Pattern33Components of a Pattern• Name(s)• Problem– Context– Real-world example• Solution– Design/structure– Implementation• Consequences• Variations, known uses34Iterator Pattern, Again• Name: Iterator (aka Cursor)• Problem:– How to process the elements of an aggregate in animplementation-independent manner?• Solution:– Define an Iterator interface• next(), hasNext(), etc. methods– Aggregate returns an instance of an implementation ofIterator interface to control the iteration35Iterator Pattern• Consequences:– Support different and simultaneous traversals• Multiple implementations of Iterator interface• One traversal per Iterator instance– Requires coherent policy on aggregate updates• Invalidate Iterator by throwing an exception, or• Iterator only considers elements present at the time of its creation• Variations:– Internal vs. external iteration• Java Iterator is external36Internal Iteratorspublic interface InternalIterator<Element> { void iterate(Processor<Element> p);}public interface Processor<Element> { public void process(Element e);}• The internal iterator applies the processor instance to eachelement of the aggregate– Thus, entire traversal happens “at once”– Less control for client, but easier to formulate traversal37Design Patterns: Goals• To support reuse of successful designs• To facilitate software evolution– Add new features easily, without breaking existing ones• In short, we want to design for change38Underlying Principles• Reduce implementation dependencies betweenelements of a software system• Sub-goals:– Program to an interface, not an implementation– Favor composition over inheritance– Use delegation39Program to Interface, Not Implementation• Rely on abstract classes and interfaces to hidedifferences between subclasses from clients– Interface defines an object’s use (protocol)– Implementation defines particular policy• Example: Iterator interface, compared to itsimplementation for a LinkedList40Rationale• Decouples clients from the implementations of theapplications they use• When clients manipulate an interface, they remainunaware of the specific object types being used.• Therefore: clients are less dependent on animplementation, so it can be easily changed later.41Favor Composition over Class Inheritance• White box reuse:– Inheritance• Black box reuse:– CompositionAClassamethodBClassamethodBClassamethodAClassamethodaVar42Rationale• White-box reuse results in implementationdependencies on the parent class– Reusing a subclass may require rewriting the parent– But inheritance easy to specify• Black-box reuse often preferred– Eliminates implementation dependencies, hidesinformation, object relationships non-static for betterrun-time flexibility– But adds run-time overhead (additional instanceallocation, communication by dynamic dispatch)43Delegation• Forward messages (delegate) to different instancesat run-time; a form of composition– May pass invoking object’s this pointer to simulateinheritanceRectanglearea()widthheightWindowarea()rectangleReturn width * heightreturn rectangle.area()44Rationale• Object relationships dynamic– Composes or re-composes behavior at run-time• But:– Sometimes code harder to read and understand– Efficiency (because of black-box reuse)45Design Patterns Taxonomy• Creational patterns– Concern the process of object creation• Structural patterns– Deal with the composition of classes or objects• Behavioral patterns– Characterize the ways in which classes or objectsinteract and distribute responsibility46Catalogue of Patterns: Creation Patterns• Singleton– Ensure a class only has one instance, and provide aglobal point of access to it.• Typesafe Enum– Generalizes Singleton: ensures a class has a fixednumber of unique instances.• Abstract Factory– Provide an interface for creating families of related ordependent objects without specifying their concreteclasses.47Structural Patterns• Adapter– Convert the interface of a class into another interfaceclients expect. Adapter lets classes work together thatcouldn't otherwise because of incompatible interfaces• Proxy– Provide a surrogate or placeholder for another object tocontrol access to it• Decorator– Attach additional responsibilities to an objectdynamically48Behavioral Patterns• Template– Define the skeleton of an algorithm in an operation,deferring some steps to subclasses• State– Allow an object to alter its behavior when its internalstate changes. The object will appear to change its class• Observer– Define a one-to-many dependency between objects sothat when one object changes state, all its dependentsare notified and updated automatically49Singleton Objects• Problem:– Some classes have conceptually one instance• Many printers, but only one print spooler• One file system• One window manager– Creating many objects that represent the sameconceptual instance adds complexity and overhead• Solution: only create one object and reuse it– Encapsulate the code that manages the reuse50The Singleton Solution• Class is responsible for tracking its sole instance– Make constructor private– Provide static method/field to allow access to the onlyinstance of the class• Benefit:– Reuse implies better performance– Class encapsulates code to ensure reuse of the object;no need to burden client51Singleton


View Full Document

UMD CMSC 433 - Design Patterns

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
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 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 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?