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:

77CMSC 433 – Programming LanguageTechnologies and ParadigmsSpring 2004Design PatternsFebruary 24, 200478Decorator Pattern: Features• Decorator conforms to interface of decoratedcomponent– Its presence is transparent to the component's clients.• Decorator forwards requests to encapsulatedcomponent– May perform additional actions before or after• Can nest decorators recursively– Allows unlimited added responsibilities• Can add/remove responsibilities dynamically79Structure80Decorator Pattern Analysis• Advantages– Fewer classes than with static inheritance– Dynamic addition/removal of decorators– Keeps root classes simple• Disadvantages– Proliferation of run-time instances– Abstract Decorator must provide common interface• Tradeoffs:– Useful when components are lightweight– Otherwise use Strategy81Decorator vs. Adapter• A decorator adds to the responsibilities of anobject– Usually has the same interface plus more features• An adapter changes the interface– But usually not the responsibilities82Template Method Pattern• Problem– You’re building a reusable class– You have a general approach to solving a problem,– But each subclass will do things differently• Solution– Invariant parts of an algorithm in parent class– Encapsulate variant parts in template methods– Subclasses override template methods– At runtime template method invokes subclass ops83Structure84Example: JUnit• Junit uses template methods pattern for run()package junit.framework;public class TestCase { ... public void run() { setUp(); runTest(); tearDown() }}• In class example, we subclass TestCase andoverride setUp() and tearDown()85Observer Pattern• Problem– Dependent must be consistent with master’s state• Solution structure: Four kinds of objects– Abstract subject• Maintain list of dependents; notifies them when master changes– Abstract observer• Define protocol for updating dependents– Concrete subject• Manage data for dependents; notifies them when master changes– Concrete observers• Get new subject state upon receiving update message86Observer Pattern87Use of Observer Pattern88Observer Pattern (cont’d)• Consequences– Low coupling between subject and observers• Subject unaware of dependents– Support for broadcasting• Dynamic addition and removal of observers– Unexpected updates• No control by the subject on computations by observers89Observer Pattern (cont’d)• Implementation issues– Storing list of observers• Typically in subject– Observing multiple subjects• Typically add parameters to update()– Who triggers update?• State-setting operations of subject– Possibly too many updates• Client– Error-prone if an observer forgets to send notification message90Observer Pattern (cont’d)• Implementation issues (cont’d)– Possibility of dangling references when subject isdeleted• Easier in garbage-collected languages• Subject notifies observers before dying– Possibility of premature notifications• Typically, method in Subject subclass calls inherited method whichdoes notification• Solve by using Template method pattern– Method in abstract class calls deferred methods, which is defined byconcrete subclasses91Observer Pattern (cont’d)• Implementation issues (cont’d)– How much information should subject send withupdate() messages?• Push model: Subject sends all information that observers may require– May couple subject with observers (by forcing a given observerinterface)• Pull model: Subject sends no information– Can be inefficient– Registering observers for certain events only• Use notion of an aspect in subject• Observer registers for one or more aspects92Observer Pattern (cont’d)• Implementation issues (cont’d)– Complex updates• Use change managers• Change manager keeps track of complex relations among (possibly)many subjects and their observers and encapsulates complex updatesto observers93Implementation Details• Observing more than one subject.– It might make sense in some situations for an observerto depend on more than one subject. The subject cansimply pass itself as a parameter in the Updateoperation, thereby letting the observer know whichsubject to examine.– Making sure Subject state is self-consistent beforenotification.94More Implementation Issues• Implementations of the Observer pattern oftenhave the subject broadcast additional informationabout the change.– At one extreme, the subject sends observers detailedinformation about the change, whether they want it ornot. At the other extreme the subject sends nothing butthe most minimal notification, and observers ask fordetails explicitly thereafter• You can extend the subject's registration interfaceto allow registering observers only for specificevents of interest.95State Pattern• Problem– An object is always in one of several known states– The state an object is in determines the behavior ofseveral methods• Solution– Could use if/case statements in each method– Better solution: use dynamic dispatch96State Pattern Approach• Encode different states as objects with samesuperclass• To change state, change the state object• Methods delegate to state object97Example – Finite State Machineclass FSM { State state; public FSM(State s) { state = s; } public void move(char c) { state = state.move(c); } public boolean accept() { return state.accept();}}public interface State { State move(char c); boolean accept();}98FSM Example – cont.class State1 implements State { static State1 instance = new State1(); private State1() {} public State move (char c) { switch (c) { case 'a': return State2.instance; case 'b': return State1.instance; default: throw new IllegalArgumentException();} } public boolean accept() {return false;}}class State2 implements State { static State2 instance = new State2(); private State2() {} public State move (char c) { switch (c) { case 'a': return State1.instance; case 'b': return State1.instance; default: throw new IllegalArgumentException(); } } public boolean accept() {return true;}}99Structure of State Pattern100Instance of State Pattern101State Pattern Notes• Can use singletons for instances of each state class– State objects don’t encapsulate (mutable) state, so canbe shared• Easy to add new states– New states can extend the base


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?