Overview of Patterns
Douglas C. Schmidt
[email protected]
www.dre.vanderbilt.edu/~schmidt
Professor of Computer Science
Institute for Software
Integrated Systems
Vanderbilt University
Nashville, Tennessee, USA
Overview of Patterns Douglas C. Schmidt
Topics Covered in this Module
• Motivate the importance of
design experience & leveraging
recurring design structure to
become a master software
developer
2
Overview of Patterns Douglas C. Schmidt
Topics Covered in this Module
• Motivate the importance of Subject Observer
design experience & leveraging state
* update
recurring design structure to observerList
state = X;
become a master software setData notify();
getData
developer notify ConcreteObserver
attach update
• Introduce patterns as a means detach doSomething
of capturing & applying proven for all observers
design experience that makes in observerList do
update()
s->getData()
software more robust to change
3
Overview of Patterns Douglas C. Schmidt
Topics Covered in this Module
• Motivate the importance of
design experience & leveraging
recurring design structure to
become a master software
developer
• Introduce patterns as a means
of capturing & applying proven
design experience that makes
software more robust to change
• Describe a process for
successfully applying patterns
to software development
projects
4
Overview of Patterns Douglas C. Schmidt
Becoming a Master Software Developer
• Software methods emphasize design notations, such as UML
• Fine for specification & documentation
5
Overview of Patterns Douglas C. Schmidt
Becoming a Master Software Developer
• Software methods emphasize design notations, such as UML
• Fine for specification & documentation
• But software is more than drawing diagrams
• Good draftsmen are not necessarily
good architects!
6
Overview of Patterns Douglas C. Schmidt
Becoming a Master Software Developer
• Software methods emphasize design notations, such as UML
• Fine for specification & documentation
Subject Observer
state * update
• But software is more than drawing diagrams
observerList
state = X;
setData notify();
getData
• Good draftsmen are not necessarily notify
attach
ConcreteObserver
update
good architects! detach doSomething
for all observers
• Good software developers rely on design experience inupdate()
observerList do s->getData()
• At least as important as knowledge of programming languages
7
Overview of Patterns Douglas C. Schmidt
Becoming a Master Software Developer
• Software methods emphasize design notations, such as UML
• Fine for specification & documentation
Subject Observer
state * update
• But software is more than drawing diagrams
observerList
state = X;
setData notify();
getData
• Good draftsmen are not necessarily notify
attach
ConcreteObserver
update
good architects! detach doSomething
for all observers
• Good software developers rely on design experience inupdate()
observerList do s->getData()
• At least as important as knowledge of programming languages
• Design experience can be codified via design & code reuse
• Design reuse: Match problem(s) to design
experience & best practices
• Code reuse: Reify proven designs within
a particular set
of domains &
development
environments
8
Overview of Patterns Douglas C. Schmidt
Leveraging Recurring Design Structures
Well-designed software systems exhibit recurring structures that promote
• Abstraction
• Flexibility
• Reuse
• Quality
• Elegance
• Modularity
Therein lies valuable design knowledge
Challenge: extracting, documenting,
communicating, applying, & preserving
this knowledge without undue time,
effort, & risk in the face of continual
change to the software!
9
Overview of Patterns Douglas C. Schmidt
Making Software that’s Robust to Changes
• Change is intrinsic to software development as requirements, use-cases,
technologies, platforms, & quality goals evolve
• Robustness to change means that software can be modified locally without
endangering overall structure
• It is a quality that
reflects ease of evolution
& maintenance costs
What is needed is a means
to address particular design
aspects of software & allow
controlled variation &
evolution of these aspects
10
Overview of Patterns Douglas C. Schmidt
Key to Mastery: Knowledge of Software Patterns
• A patterns describes solution(s) to common problem(s) arising within a
context by
• Naming a recurring design structure
Jug
Handle
pattern
11
Overview of Patterns Douglas C. Schmidt
Key to Mastery: Knowledge of Software Patterns
• A patterns describes solution(s) to common problem(s) arising within a
context by
Subject
• Naming a recurring design structure
Observer
ConcreteObserver
Observer
pattern
“define a one-to-many dependency
between objects so that when one
object changes state, all
dependents are notified & updated”
12
Overview of Patterns Douglas C. Schmidt
Key to Mastery: Knowledge of Software Patterns
• A patterns describes solution(s) to common problem(s) arising within a
context by
Subject
• Naming a recurring design structure
Observer
* update
state
• Specifying design structure explicitly observerList state = X;
notify();
by identifying key classes/objects* setData
ConcreteObserver
getData
• Roles & relationships notify Observer update
pattern
attach doSomething
• Dependencies detach
• Interactions for all observers
in observerList do s->getData()
• Conventions update()
*Interpret “class” & “object” loosely: patterns
13 are for more than OO languages!
Overview of Patterns Douglas C. Schmidt
Key to Mastery: Knowledge of Software Patterns
• A patterns describes solution(s) to common problem(s) arising within a
context by
Subject
• Naming a recurring design structure
Observer
* update
state
• Specifying design structure explicitly observerList state = X;
notify();
by identifying key classes/objects setData
ConcreteObserver
getData
• Roles & relationships notify Observer update
pattern
attach doSomething
• Dependencies detach
• Interactions for all observers
in observerList do s->getData()
• Conventions update()
• Abstracting from concrete design
elements, e.g., problem domain,
programming language, vendor, etc.
14
Overview of Patterns Douglas C. Schmidt
Key to Mastery: Knowledge of Software Patterns
• A patterns describes solution(s) to common problem(s) arising within a
context by
Subject
• Naming a recurring design structure
Observer
* update
state
• Specifying design structure explicitly observerList state = X;
notify();
by identifying key classes/objects setData
ConcreteObserver
getData
• Dependencies notify Observer update
pattern
attach doSomething
• Roles & Relationships detach
• Interactions for all observers
in observerList do s->getData()
• Conventions update()
• Abstracting from concrete design
elements, e.g., problem domain,
programming language, vendor, etc.
• Distilling & codifying knowledge gleaned
from successful design experience
15
Overview of Patterns Douglas C. Schmidt
Common Characteristics of Patterns
• They are independent of
programming languages &
implementation techniques
16
Overview of Patterns Douglas C. Schmidt
Common Characteristics of Patterns
• They are independent of Subject Observer
programming languages & * update
implementation techniques state
observerList
• They define “micro-architectures” state = X;
setData notify();
• i.e., a “society of objects” getData
notify ConcreteObserver
attach update
detach doSomething
for all observers
in observerList do s->getData()
update()
17
Overview of Patterns Douglas C. Schmidt
Common Characteristics of Patterns
• They are independent of public class EventHandler extends Observer {
programming languages & public void update(Observable obj,
implementation techniques Object arg)
{ /* … */ }
• They define “micro-architectures” …
• i.e., a “society of objects” public class EventSource extends Observable,
implements Runnable {
• They aren’t code or (concrete) public void run()
designs, so they must be reified { /* … */ notifyObservers(/* … */); }
& applied in particular languages …
EventSource eventSource =
new EventSource();
EventHandler eventHandler =
Observer new Event_Handler();
pattern in Java eventSource.addObserver(eventHandler);
Thread thread = new Thread(eventSource);
thread.start();
…
18
Overview of Patterns Douglas C. Schmidt
Common Characteristics of Patterns
• They are independent of class Event_Handler : public Observer { public:
programming languages & virtual void update(Observable obj,
implementation techniques Object arg)
{ /* … */ }
• They define “micro-architectures” …
• i.e., a “society of objects”class Event_Source : public Observable,
public Runnable { public:
• They aren’t code or (concrete) virtual void run()
designs, so they must be reified { /* … */ notify_observers(/* … */); }
& applied in particular languages …
Event_Source event_source =
Observer pattern in C++ new Event_Source_Impl;
(uses the GoF Bridge pattern Event_Handler event_handler =
with reference counting to new Event_Handler_Impl;
simplify memory event_source->add_observer(event_handler);
management & ensure Thread thread = new Thread(event_source);
exception-safe semantics) thread->start();
…
19
Overview of Patterns Douglas C. Schmidt
Common Characteristics of Patterns
• They are independent of
programming languages &
implementation techniques
• They define “micro-architectures”
• i.e., a “society of objects”
• They aren’t code or (concrete)
designs, so they must be reified
& applied in particular languages
• They are not methods, but can be used
an adjunct to other methods
• e.g., Rational Unified Process, Agile, etc.
• There are also patterns for organizing
effective software development teams &
navigating other complex settings
20
Overview of Patterns Douglas C. Schmidt
Common Parts of a Pattern Description
• Name & statement of pattern intent
• Problem addressed by pattern
• Including “forces” & “applicability”
• Solution
• Visual & textual descriptions of
pattern structure & dynamics
• Consequences
• Pros & cons of applying the pattern
• Implementation guidance
• May include source code examples
• Known uses
• “rule of three”
• Related patterns
• Tradeoffs between alternative patterns
21for more info on pattern forms
See c2.com/cgi/wiki?PatternForms
Overview of Patterns Douglas C. Schmidt
Process for Applying Patterns
• To apply patterns successfully,
software developers need to:
• Have broad knowledge of patterns
relevant to their domain(s)
22
Overview of Patterns Douglas C. Schmidt
Process for Applying Patterns
• To apply patterns successfully,
software developers need to:
• Have broad knowledge of patterns
relevant to their domain(s)
• Evaluate trade-offs & impact of using Template
certain patterns in their software Method
pattern
Strategy
pattern
23
Overview of Patterns Douglas C. Schmidt
Process for Applying Patterns
• To apply patterns successfully,
software developers need to: Content Content
• Have broad knowledge of patterns Observable Observer
* onChange
relevant to their domain(s) state
observerList
• Evaluate trade-offs & impact of using
certain patterns in their software registerObserver
unregisterObserver
notifyChange
• Make design & implementation EventHandler
decisions about how best to apply onChange
…
the selected patterns for all observers
in observerList do
onChange()
• Patterns may require slight
modifications for particular contexts
One use of the Observer
Pattern in Android
24
Overview of Patterns Douglas C. Schmidt
Process for Applying Patterns
• To apply patterns successfully,
software developers need to:
Context Broadcast
• Have broad knowledge of patterns Receiver
* onReceive
relevant to their domain(s) state
observerList
• Evaluate trade-offs & impact of using
certain patterns in their software registerReceiver
unregisterReceiver
sendBroadcast
• Make design & implementation BroadcastHandler
decisions about how best to apply onReceive
…
the selected patterns for all observers
in observerList do
onReceive()
• Patterns may require modifications
for particular contexts
A different use of the
Observer Pattern in Android
25
Overview of Patterns Douglas C. Schmidt
Process for Applying Patterns
• To apply patterns successfully, If (uniqueInstance == 0)
software developers need to: uniqueInstance =
new Singleton;
return uniqueInstance;
• Have broad knowledge of patterns
relevant to their domain(s) Singleton pattern vs.
• Evaluate trade-offs & impact of using Double-Checked
Locking Optimization
certain patterns in their software
Pattern
class Singleton {
• Make design & implementation public:
decisions about how best to apply static Singleton *instance () {
// First check
the selected patterns if (instance_ == 0) {
Guard<Thread_Mutex> g(lock_);
• Patterns may require modifications if (instance_ == 0) // Double check
instance_ = new Singleton;
for particular contexts }
return instance_;
}
private:
static Singleton *instance_;
static Thread_Mutex lock_;
};
26
Overview of Patterns Douglas C. Schmidt
Process for Applying Patterns
• To apply patterns successfully,
software developers need to:
• Have broad knowledge of patterns
relevant to their domain(s)
• Evaluate trade-offs & impact of using
certain patterns in their software
• Make design & implementation
decisions about how best to apply
the selected patterns
• Patterns may require modifications
for particular contexts
• Combine with other patterns &
implement/integrate with code
27
Overview of Patterns Douglas C. Schmidt
Summary
• Patterns support • Patterns can be applied in all
• Design at a more abstract level software lifecycle phases
• Treat many class/object • Analysis, design, & reviews
interactions as a conceptual unit • Implementation &
• Emphasize design qua design, not documentation
(obscure) language features • Testing & optimization
• Provide ideal targets for design • Reuse & refactoring
refactoring • Resist urge to brand everything as
• Variation-oriented design process a pattern
1. Determine which design elements • Articulate specific benefits &
can vary demonstrate general
2. Identify applicable pattern(s) applicability
3. Vary patterns & evaluate trade-offs • e.g., find three different
existing examples from code
4. Repeat…
other than your own!
28 but can apply to non-OO languages
Patterns often equated with OO languages,
