Transcript A design pattern

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. Name
- plus possible aliases
2. Problem
- including context and forces
3. Solution
- structure, dependencies & interactions
4. Consequences
- plus alternative implementation strategies
and trade-offs
3
A design pattern (cont.)
•
a micro-architecture
– class/object interactions as a unit
– improve flexibility and restructuring
– distill and generalize oo design experience
•
language- and implementation-independent
– described by simple UML diagrams
– aid to novices and experts alike
•
common vocabulary
– enhance understanding, documentation, and
team communication
4
Example: The Observer design pattern
• known uses: Smalltalk Model-View-Controller (MVC),
GUI component listeners in Java
5
Example: Observer (cont.)
• define an 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
Structure
6
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
7
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
8
The Composite design pattern
• treat multiple individual objects and recursivelycomposed objects (trees) uniformly
– provides extensibility: new components work
wherever old ones do
• known uses: file directories, abstract syntax trees
(AST), Java GUI component-container
Structure
other
versions
have been
presented
9
The Strategy design pattern
• 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 relation for data structures,
GUI component layout managers
Structure
10
The Iterator design pattern
• access elements of a container without exposing its
representation
– multiple traversal algorithms over a container
– container classes and traversal algorithms can
vary independently
• known uses: C++ STL, Java Iterators; originally: Clu
Structure
11
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 (e.g., Java GUI peer components)
• 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
12
Design space for GoF patterns
scope: domain over which a pattern applies
purpose: reflects what a pattern does
13
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 design pattern
– state a specific but general problem and benefits
– must demonstrate wide applicability (at least three
examples - from code other than your own)
– pattern design even harder than OO design
14