Design Patterns
Software Architecture 48433 21st August 2003
Background
Gamma, Helm, Johnson, and Vlissides (the Gang of Four ) Design Patterns, Elements of Reusable Object-Oriented Software This book solidified thinking about patterns and became the seminal Design Patterns text Software design patterns are based (somewhat) on work by the architect Christopher Alexander
Purpose
A design pattern captures design expertise patterns are not created from thin air, but abstracted from existing design examples Using design patterns is reuse of design expertise Studying design patterns is a way of studying how the experts do design Design patterns provide a vocabulary for talking about design
On vocabulary
Longitudinally-mounted 90-degree V-twin
Torque Perfect primary balance Growl
Images from http://www.ducati.com
On vocabulary (2)
Transverse inline four
Power peak
Screamer
Images from http://www.tntperformancedyno.com, http://dsr.racer.net and http://www.motorcycle.com
Why design patterns in SA?
If you re a software engineer, you should know about them anyway There are many architectural patterns published, and the GoF Design Patterns is a prerequisite to understanding these:
Mowbray and Malveau CORBA Design Patterns Schmidt et al Pattern-Oriented Software Architecture
Design Patterns help you break out of firstgeneration OO thought patterns
The seven layers of architecture*
Global architecture Enterprise architecture System architecture Application architecture Macro-architecture Micro-architecture Objects
Frameworks Design patterns OO architecture
ORB
Subsystem
OO programming
* Mowbray and Malveau
How patterns arise
Problem
Forces Solution Benefits Related Patterns Consequences
Structure of a pattern
Name Intent Motivation Applicability Structure Consequences Implementation Known Uses Related Patterns
Key patterns
The following patterns are what I consider to be a good basic set of design patterns Competence in recognizing and applying these patterns will improve your low-level design skills (The slides are necessarily brief and do not follow the structure just given above!)
Composite
Construct part-whole hierarchy Simplify client interface to leaves/composites Easier to add new kinds of components
Client
Component
Operation() Add(Component) Remove(Component)
0..*
children
Leaf
Operation()
Composite
Operation() Add(Component) Remove(Component)
For all c in children c.Operation();
Composite (2)
Example: figures in a structured graphics toolkit
Controller View
0..*
Figure
paint() translate() getBounds()
0..* children
LabelFigure BasicFigure CompositeFigure
paint() paint() paint() addFigure(Figure)) removeFigure(Figure))
parent
For all c in children c.paint();
Facade
Provide unified interface to interfaces within a subsystem Shield clients from subsystem components Promote weak coupling between client and subsystem components
Client Facade
Faade (2)
Example: graph interface to a simulation engine
SchematicEditor Graph
2
Director
0..*
Relation
Port
Entity
BufferedRelation o en
AtomicEntity Actor
CompositeEntity
Strategy
Make algorithms interchangeable--- changing the guts Alternative to subclassing Choice of implementation at run-time Increases run-time complexity
Context
ContextInterface()
Strategy
Operation()
ConcreteStrategy1 ConcreteStrategy2
Operation() Operation()
Strategy (2)
Example: drawing different connector styles
shape=router.recalculate(start,end); redraw(shape);
Connector
route()
ConnectorRouter
Shape recalculate(Pt, Pt)
StraightRouter
Shape recalculate(Pt, Pt)
ArcRouter
Shape recalculate(Pt, Pt)
ManhattanRouter
Shape recalculate(Pt, Pt)
Observer
Many-to-one dependency between objects Use when there are two or more views on the same data aka Publish and subscribe mechanism Choice of push or pull notification styles
Subject
attach(Observer) detach(Observer) notify()
Observer
forall o in observers o.update()
update()
ConcreteSubject
getState()
ConcreteObserver
update()
state=subject.getState();
Observer Observer(2)
Example: subscribing to events
(Diagram not done, sorry!)
Factory Method
Defer object instantiation to subclasses Eliminates binding of application-specific subclasses Connects parallel class hierarchies A related pattern is AbstractFactory
Product
operation()
Creator
Product createProduct()
ConcreteProduct
operation()
ConcreteCreator
Product createProduct()
return new ConcreteProduct();
Factory Method (2)
Example: creating manipulators on connectors
Interactor Figure
createManipulator()
0..1
Manipulator
attach(Figure)
RectFigure
createManipulator()
Connector BoundsManipulator ArcManipulator
createManipulator() attach(Figure) attach(Figure)
mani mani new B nd Mani
new ArcMani lat r();
lat r();
Chain of Responsibility
Decouple sender of a request from receiver Give more than one object a chance to handle Flexibility in assigning responsibility Often applied with Composite
successor
Client
ContextInterface()
Handler
handleRequest()
ConcreteHandler1
handleRequest()
ConcreteHandler2
handleRequest()
Chain of Responsibility (2)
Example: handling events in a graphical hierarchy
If interactor != null interactor.handle(event,this) else parent.handleEvent(event) 0..1 0..* 0..* children
Interactor
handle(Event,Figure)
Figure
handleEvent(Event)
CompositeFigure
parent
Patterns vs Design
Patterns are design
But: patterns transcend the identify classes and associations approach to design Instead: learn to recognize patterns in the problem space and translate to the solution
Patterns can capture OO design principles within a specific domain Patterns provide structure to design
Patterns vs Frameworks
Patterns are lower-level than frameworks Frameworks typically employ many patterns:
Factory Strategy Composite Observer
Done well, patterns are the plumbing of a framework
Patterns vs Architecture
Design Patterns (GoF) represent a lower level of system structure than architecture (cf: seven levels of A) Patterns can be applied to architecture:
Mowbray and Malveau Buschmann et al Schmidt et al
Architectural patterns tend to be focussed on middleware. They are good at capturing:
Concurrency Distribution Synchronization
Online resources
Pattern FAQ
http://g.oswego.edu/dl/pd-FAQ/pd-FAQ.html
Basic patterns
http://exciton.cs.oberlin.edu/javaresources/Des ignPatterns/default.htm
Patterns home page
http://hillside.net/patterns/
Concluding remarks
Design Patterns (GoF) provide a foundation for further understanding of:
Object-Oriented design Software Architecture Re-reading them over time helps As does applying them in your own designs!
Understanding patterns can take some time
