A Brief Introduction
to Design Patterns
Based on materials from Doug Schmidt
Object-oriented design
OOD methods emphasize design notations
Fine for specification, documentation
But OOD is more than just drawing diagrams
Good draftsmen, good designers
Good OO designers rely on lots of experience
At least as important as syntax
Most powerful reuse is design reuse
Match problem to design experience
OO systems exhibit recurring structures that
promote: abstraction, flexibility, modularity,
elegance
2
A design pattern
Abstracts a recurring design structure
Comprises class and/or object
dependencies
structures
interactions
conventions
Names and specifies the design structure
explicitly
Distills design experience
3
Four basic parts
1. Name
2. Problem
3. Solution
4. Trade-offs of application
Example: Observer
pattern
Observer pattern
components [1/2]
Observer pattern
components [2/2]
Design patterns goals
Codify good design
distill & generalize experience
aid to novices & experts alike
Give design structures explicit names
common vocabulary
reduced complexity
greater expressiveness
Capture & preserve design information
articulate design decisions succinctly
improve documentation
Facilitate restructuring/refactoring
patterns are interrelated
additional flexibility
8
GoF design patterns
GoF: Erich Gamma, Richard Helm,Ralph JohnsonandJohn Vlissides
Scope: domain over which a pattern applies
Purpose: reflects what a pattern does
9
Design pattern
template [1/2]
Intent
short description of the pattern & its purpose
Also Known As
Any aliases this pattern is known by
Motivation
motivating scenario demonstrating patterns use
Applicability
circumstances in which pattern applies
Structure
graphical representation of the pattern using modified UML
notation
Participants
participating classes and/or objects & their responsibilities
10
Design pattern
template [2/2]
Collaborations
how participants cooperate to carry out their
responsibilities
Consequences
the results of application, benefits, liabilities
Implementation
pitfalls, hints, techniques, plus language-dependent
issues
Sample Code
sample implementations in C++, Java, C#, Smalltalk,
C, etc.
Known Uses
examples drawn from existing systems
11
UML/OMT notation
12
Observer design pattern [1/3]
Intent
define a one-to-many dependency between objects so that when one object changes state,
all dependents are notified & updated
Applicability
an abstraction has two aspects, one dependent on the other
a change to one object requires changing untold others
an object should notify unknown other objects
Structure
13
Observer design pattern [2/3]
class ProxyPushConsumer : public //
virtual void push (const CORBA::Any &event) {
for (std::vector<PushConsumer>::iterator i
(consumers.begin ()); i != consumers.end (); i++)
(*i).push (event);
}
class MyPushConsumer : public // .
virtual void push
(const CORBA::Any &event) { /* consume the event. */ }
14
Observer design pattern [3/3]
Consequences
+ modularity: subject & observers may vary independently
+ extensibility: can define & add any number of observers
+ customizability: different observers offer different views of subject
unexpected updates: observers dont know about each other
update overhead: might need hints or filtering
Implementation
subject-observer mapping
dangling references
update protocols: the push & pull models
registering modifications of interest explicitly
Known Uses
Smalltalk Model-View-Controller (MVC)
InterViews (Subjects & Views, Observer/Observable)
Andrew (Data Objects & Views)
Pub/sub middleware (e.g., CORBA Notification Service, Java Messaging Service)
Mailing lists
15
Benefits of design
patterns
Design reuse
Uniform design vocabulary
Enhance understanding, restructuring, &
team communication
Basis for automation
Transcends language-centric
biases/myopia
Abstracts away from many unimportant
details
16
Another example pattern: Template
Provides a skeleton of an algorithm in a method, deferring some steps
to subclasses
class Base_Class {
public:
// Template Method.
void template_method (void) {
hook_method_1 ();
hook_method_2 ();
// ...
}
virtual void hook_method_1 () = 0;
virtual void hook_method_2 () = 0;
};
class Derived_Class_1 : public Base_Class {
virtual void hook_method_2 () { /* ... */ }
};
class Derived_Class_2 : public Base_Class {
virtual void hook_method_1 () { /* ... */ }
virtual void hook_method_2 () { /* ... */ }
};
17
Yet another design
pattern: adapter
When two software components
(e.g., legacy code and new
development or a COTS) cannot
interface
Adapter changes interface of one so
the other can use it
Adapter fills the gap b/w two interfaces
No changes needed for either
18
Yet another design
pattern: adapter [2/2]
class NewTime
{
public:
int GetTime() {
return otime.get_time() * 100;
}
private:
OriginalTime otime;
};
An alternate: a wrapper
19
Relationship with other
design concepts
20
