Design Patterns

1
Design Patterns

• John Reekie
• john.reekie_at_uts.edu.au

Software Architecture 48433 21st August 2003
2
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

3
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

4
On vocabulary

• Longitudinally-mounted 90-degree V-twin

Torque
Growl
Perfect primary balance
Images from http//www.ducati.com
5
On vocabulary (2)

• Transverse inline four

Power peak
Screamer
Images from http//www.tntperformancedyno.com, htt
p//dsr.racer.net and http//www.motorcycle.com
6
Why design patterns in SA?

• If youre 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
  first-generation OO thought patterns

7
The seven layers of architecture
OO architecture
Global architecture
Enterprise architecture
Subsystem
System architecture
Application architecture
Frameworks
Macro-architecture
Design patterns
Micro-architecture
Objects
OO programming
Mowbray and Malveau
8
How patterns arise
Problem
Context
Forces
Solution
Benefits
Consequences
Related Patterns
9
Structure of a pattern

• Name
• Intent
• Motivation
• Applicability
• Structure
• Consequences
• Implementation
• Known Uses
• Related Patterns

10
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!)

11
Composite

• Construct part-whole hierarchy
• Simplify client interface to leaves/composites
• Easier to add new kinds of components

0..
Component
Client
Operation() Add(Component) Remove(Component)
children
Composite
Leaf
Operation() Add(Component) Remove(Component)
Operation()
For all c in children c.Operation()
12
Composite (2)

• Example figures in a structured graphics toolkit

Controller
0..
0..
Figure
View
children
paint() translate() getBounds()
CompositeFigure
BasicFigure
LabelFigure
parent
paint() addFigure(Figure)) removeFigure(Figure))
paint()
paint()
For all c in children c.paint()
13
Facade

• Provide unified interface to interfaces within a
  subsystem
• Shield clients from subsystem components
• Promote weak coupling between client and
  subsystem components

Client
Facade
14
Façade (2)

• Example graph interface to a simulation engine

SchematicEditor
Graph
Director
2
0..
Entity
Port
Relation
CompositeEntity
AtomicEntity
BufferedRelation
Actor
Token
15
Strategy

• Make algorithms interchangeable---changing the
  guts
• Alternative to subclassing
• Choice of implementation at run-time
• Increases run-time complexity

Strategy
Context
Operation()
ContextInterface()
ConcreteStrategy2
ConcreteStrategy1
Operation()
Operation()
16
Strategy (2)

• Example drawing different connector styles

shaperouter.recalculate(start,end) redraw(shape)

ConnectorRouter
Connector
Shape recalculate(Pt, Pt)
route()
ArcRouter
StraightRouter
ManhattanRouter
Shape recalculate(Pt, Pt)
Shape recalculate(Pt, Pt)
Shape recalculate(Pt, Pt)
17
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
Observer
attach(Observer) detach(Observer) notify()
update()
forall o in observers o.update()
ConcreteObserver
ConcreteSubject
update()
getState()
statesubject.getState()
18
Observer(2)
Observer

• Example subscribing to events

(Diagram not done, sorry!)
19
Factory Method

• Defer object instantiation to subclasses
• Eliminates binding of application-specific
  subclasses
• Connects parallel class hierarchies
• A related pattern is AbstractFactory

Creator
Product
Product createProduct()
operation()
ConcreteCreator
ConcreteProduct
Product createProduct()
operation()
return new ConcreteProduct()
20
Factory Method (2)

• Example creating manipulators on connectors

Interactor
0..1
Figure
Manipulator
createManipulator()
attach(Figure)
ArcManipulator
BoundsManipulator
Connector
RectFigure
attach(Figure)
attach(Figure)
createManipulator()
createManipulator()
manip new ArcManipulator()
manip new BoundsManipulator()
21
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
Handler
Client
handleRequest()
ContextInterface()
ConcreteHandler2
ConcreteHandler1
handleRequest()
handleRequest()
22
Chain of Responsibility (2)

• Example handling events in a graphical hierarchy

If interactor ! null interactor.handle(event,th
is) else parent.handleEvent(event)
0..
0..1
0..
Figure
Interactor
children
handleEvent(Event)
handle(Event,Figure)
CompositeFigure
parent
23
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

24
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

25
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

26
Online resources

• Pattern FAQ
• http//g.oswego.edu/dl/pd-FAQ/pd-FAQ.html
• Basic patterns
• http//exciton.cs.oberlin.edu/javaresources/Design
  Patterns/default.htm
• Patterns home page
• http//hillside.net/patterns/

27
Concluding remarks

• Design Patterns (GoF) provide a foundation for
  further understanding of
• Object-Oriented design
• Software Architecture
• Understanding patterns can take some time
• Re-reading them over time helps
• As does applying them in your own designs!