DOC PREVIEW
UMD CMSC 433 - Design Patterns

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

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

Unformatted text preview:

37CMSC 433 – Programming LanguageTechnologies and ParadigmsSpring 2004Design PatternsFebruary 19, 200438Design Patterns: Goals• To support reuse, of– Successful designs– Existing code• To facilitate software evolution– Add new features easily, without breaking existing ones• In short, we want to design for change39Underlying Principles• Reduce implementation dependencies betweenelements of a software system• Sub-goals:– Program to an interface, not an implementation– Favor composition over inheritance– Use delegation40Program 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 LinkedList41Rationale• 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.42Favor Composition over Class Inheritance• White box reuse:– Inheritance• Black box reuse:– CompositionAClassamethodBClassamethodBClassamethodAClassamethodaVar43Rationale• White-box reuse has 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)44Delegation• 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()45Rationale• 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)46Design 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 responsibility47Catalogue 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.48Structural 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 objectdynamically49Behavioral 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 automatically50Singleton 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 reuse51The 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 client52Singleton pattern53Implementing the Singleton method• In Java, just define a final static fieldpublic class Singleton { private Singleton() {…} final private static Singleton instance= new Singleton(); public static Singleton getInstance() { return instance; }}• Java semantics guarantee object is createdimmediately before first use54Marshalling• Marshalling is the process of transforminginternal data into a form that can be– Written to disk– Sent over the network– Etc.• Unmarshalling is the inverse process55Marhsalling in Java• Java provides support for marshalling objects– Classes implement the Serializable interface– The JVM imlpements standard marhsalling andunmarshalling automatically• E.g., enables you to create persistent objects, stored on disk• This can be useful for build a light-weight database• Also useful for distributed object systems• Often, generic implementation works fine– But let’s consider singletons...56Marhsalling and Singletons• What happens when we unmarshall a singleton?• Problem: JVM doesn’t know about singletons– It will create two instances of Singleton.instance!– Oops!Singleton.instance Singleton.instance57Marhsalling and Singletons (cont’d)• Solution: Implement– Object readResolve() throws ObjectStreamException;• This method will be called after standard unmarshilling• Returned result is substituted for standard unmarshalled result• E.g., add to Singleton class the following method– Object readResolve() { return instance; }• Do we need to worry about marshalling?• Notes: Serialization is a big hack!– Doesn’t follow language conventions58Generalizing Singleton: Typesafe Enum• Problem:– Need a number of unique objects, not just one– Basically want a C-style enumerated type, but safe• Solution:– Generalize the Singleton Pattern to keep track ofmultiple, unique objects (rather than just one)59Typesafe Enum PatternEnumstatic Enum inst1static Enum inst2EnumOp ()EnumEnumEnumOp ()EnumOp ()datadatadataNote: constructor is private60Typesafe Enum: Examplepublic class Suit { private final String name; private Suit(String name) { this.name = name; }


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?