Design Patterns

John Reekie john.reekie@uts.edu.au

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