Transcript An Introduction to Design Patterns John Vlissides IBM T.J. Watson

An introduction to
design patterns
Based on material produced by
John Vlissides and Douglas C. Schmidt
1
Background
• object-oriented design is hard
• good OO designers rely on lots of experience
• OO systems contain recurring structures that exhibit
– abstraction, modularity, elegance, and flexibility
– balancing between various design trade-offs
– valuable design knowledge
• most general reuse is design reuse
– matching problems to design experiences
Problem: capturing, communicating, and applying this
knowledge
2
A design pattern
1.
2.
3.
4.
Name (possible aliases)
Problem (including “forces”)
Solution (structures, dependencies & interactions)
Consequences and trade-offs of its application
•
a micro-architecture: class/object interactions as a
unit
– improve flexibility and restructuring
– distill and generalize oo design experience
language- and implementation-independent
– aid to novices and experts alike
common vocabulary: enhance understanding,
documentation, and team communication
•
•
3
Example: The Observer design pattern
• known uses: Smalltalk Mode-View-Controller (MVC),
GUI component listeners in Java
4
Example: Observer (cont.)
Structure
• define a one-to-many dependency between objects
so that when one object changes, all dependents are
notified and updated
– decoupling of subjects and observers
– different observers offer different views of subject
– can define and add any number of observers
5
Principles of design patterns
• patterns give recurring solutions to (nontrivial)
problems; solutions that have been tried over and
over and approved by experts
– design patterns are not invented but found (in
existing systems)
• often provide a level of indirection that keeps classes
from having to know about each other’s internals
– give ways to make some structures or behavior
modifiable or replaceable
– usually, by objectifying some aspect of the system
• generally, help you write more reusable programs
6
Principles of design patterns (cont.)
Different kinds of practices and reusable designs:
(1) idioms - techniques for expressing low-level, mostly
language-dependent ideas
– e.g., ref counts in C++, inner classes in Java
(2) design patterns - medium-scale, mostly languageindependent abstractions
– use oo mechanisms, described by UML diagrams
(3) software frameworks - consist of source code with
variant parts, into which the user can plug-in
specific code to provide the required structure and
behavior
– GUI libraries, data structure libraries
7
The Composite design pattern
Structure
• treat individual objects and multiple, recursivelycomposed objects (trees) uniformly
– provides extensibility: new components work
wherever old ones do
• known uses: file directories, abstract syntax trees
(AST) in compilers, Java GUI component-container
8
The Strategy design pattern
Structure
• encapsulate a family of algorithms, and make them
interchangeable
– can change algorithms dynamically (at run time)
– in C++, static strategy selection can be done via
templates and type parameters
• known uses: ordering for data structures, Java GUI
component layout managers
9
The Iterator design pattern
Structure
• access elements of a container without exposing its
representation
– multiple traversal algorithms over a container
– container classes and traversal algorithms can
vary independently
• uses: C++ STL iterators, Java collection iterators, etc.
10
Other design patterns
• the Template Method makes part(s) of an algorithm
changeable: the skeleton of an algorithm defers
some steps to subclasses
• the Singleton ensures a class only has one
instance, and provides a global point of access to it
(i.e., manages global objects)
• the Bridge pattern separates interface and
implementation hierarchies, and allows them vary
independently
• the Abstract Factory provides an interface for
creating families of related or dependent objects
without specifying their concrete classes
– uses Factory Methods or Prototypes to create
the actual instances; the factory object is often a
Singleton
11
Design space for GoF patterns
scope: domain over which a pattern applies
purpose: reflects what a pattern does
12
Drawbacks/limitations of design patterns
• a pattern is an idea of solution: may require tedious
and error-prone human effort to implement as code
– but may provide the basis for automation
• cannot apply them blindly
– must consider what design aspects are variable
– a pattern may leave important details unresolved
– added indirection increases complexity and cost
• don't label everything a pattern
– state specific problem and benefits
– must demonstrate wide applicability (at least three
examples - from code other than your own)
• pattern design even harder than OO design
13