Overview of Design Patterns

Vijayan Sugumaran

Department of DIS

Oakland University

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

Background Erich Gamma, Richard Helm, Ralph Johnson,

and John Vlissides (the “Gang of Four”) – “Design Patterns: Elements of Reusable Object-Oriented Software” published in 1995, by Addison-Wesley

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 – work on pattern language

Design Patterns

Design pattern - a common solution to a give problem in a given context, which supports reuse of proven approaches and techniques.

Advantages Allow us to design with the experiences of those

who came before rather than having to "reinvent the wheel."

Provide designers a short-hand notation for discussing design issues.

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

The seven layers of architecture*

Global architectureEnterprise architecture

System architecture

Application architecture

Macro-architecture

Micro-architecture

Objects

* Mowbray and Malveau

ORB

OO architecture

Frameworks

Subsystem

Design patterns

OO programming

How patterns arise

Benefits

Related Patterns

Consequences

Forces

Problem

Context

Solution

Structure of a pattern Name Intent Motivation Applicability Structure Consequences Implementation Known Uses Related Patterns

Key patterns

The following patterns are considered to be a good “basic” set of design patterns

Competence in recognizing and applying these patterns will improve your low-level design skills

Gang-of-Four PatternsCreationalAbstract factor

Builder

Factory method

Prototype

Singleton

StructuralAdapter

Bridge

Composite

Decorator

Façade

Proxy

BehavioralChain of responsibility

Command

Flyweight

Interpreter

Iterator

Mediator

Memento

Observer

State

Strategy

Template method

Visitor

Adapter PatternPattern: AdapterCategory: StructuralProblem: How to provide a stable interface to similar classes with

different interfaces?Solution: Add a class that acts as an adapter to convert the interface

of a class into another interface that the client classes expect.

Composite Pattern

ComponentOperation()Add(Component)Remove(Component)

CompositeOperation()Add(Component)Remove(Component)

LeafOperation()

Client

children

0..*

For all c in children c.Operation();

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

Composite Pattern Example

Figurepaint()translate()getBounds()

CompositeFigurepaint()addFigure(Figure))removeFigure(Figure))

BasicFigurepaint()

Viewchildren

0..*

For all c in children c.paint();

Example: figures in a structured graphics toolkit

LabelFigurepaint()

0..*

Controller

parent

Strategy Pattern

StrategyOperation()

ConcreteStrategy2Operation()

Context

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

ContextInterface()

ConcreteStrategy1Operation()

Strategy Pattern Example

ConnectorRouterShape recalculate(Pt, Pt)

ArcRouterShape recalculate(Pt, Pt)

Connectorroute()

StraightRouterShape recalculate(Pt, Pt)

ManhattanRouterShape recalculate(Pt, Pt)

shape=router.recalculate(start,end);redraw(shape);

Example: drawing different connector styles

Chain of Responsibility Pattern

HandlerhandleRequest()

ConcreteHandler2handleRequest()

ClientContextInterface()

ConcreteHandler1handleRequest()

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

Chain of Responsibility Pattern Example

FigurehandleEvent(Event)

CompositeFigure

Interactorchildren

0..*

If interactor != null interactor.handle(event,this)else parent.handleEvent(event)

0..1

parent

Example: handling events in a graphical hierarchy

handle(Event,Figure)

0..*

Abstract Factory Pattern

1. Consider a user interface toolkit to support multiple look-and-feel standards.

2. For portability an application must not hard code its widgets for one look and feel.

How to design the application so that incorporating new look and feel requirements will be easy?

Problem Context:

Abstract Factory Pattern Example

Define an abstract WidgetFactory class This class declares an interface to create

different kinds of widgets There is one abstract class for each kind of

widget and concrete subclasses implement widgets for different standards

WidgetFactory offers an operation to return a new widget object for each abstract widget class. Clients call these operations to obtain instances of widgets without being aware of the concrete classes they use

Abstract Factory Pattern Example

WidgetFactory

CreateScrollbar()

CreateWindow()

Window

ScrollBarWWidgetFactory

MacWidgetFactory

Client

WWindowMacWindow

MacScrollBar WScrollBar

One for each standard.

Abstract Factory Pattern Example

AbstractFactory

CreateScrollbar()

CreateWindow()

ConcreteFactory1

Client

ProductA1ProductA2

AbstractProductA

ProductB2 ProductB1

AbstractProductB

ConcreteFactory2

CreateProductA()

CreateProductB()

Abstract Factory Pattern: Participants and Communication

ConcreteFactory: Implements the operations to create concrete product objects.

AbstractProduct: Declares an interface for a type of product object.

ConcreteProduct: Defines a product object to be created by the corresponding factory.

AbstractFactory: Declares the interface for operations to create abstract product objects

Client: Uses only the interface declared by the abstractFactory and AbstractProduct classes.

Abstract Factory Pattern Codeclass MazeFactory {

public:

MazeFactory();

virtual Maze* MakeMaze() const

{ return new Maze;}

// Creates components of mazes. // Builds rooms, walls, and doors.

virtual Wall* MakeWall() const

{ return new Wall;}

virtual Wall* MakeRoom(int n) const

{ return new Room;}

}// more methods.

// This factory is a collection of // factory methods. Also, this class// acts both as Abstract and Concrete // Factory

Abstract Factory Pattern CodeMaze* MazeGame:: CreateMaze (MazeFactory& factory)

Maze* aMaze = factory.MakeMaze();

// Builds a maze.

}

Room* myroom = factory.MakeRoom(1);

Door* aDoor = factory.MakeDoor(myRoom,herRoom)

Room* herroom = factory.MakeRoom(2);

aMaze AddRoom(myRoom)

aMaze AddRoom(herRoom)

// More code to add walls.

// One can also create a// BombedMazeFactory with // different types of Rooms // and Walls.

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

Summary 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!