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,