1

An introduction to design patterns

Based on material produced by John Vlissides and Douglas C. Schmidt

2

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

3

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

4

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

5

Example: The Observer design pattern

• known uses: Smalltalk Model-View-Controller (MVC), GUI component listeners in Java

6

Example: Observer (cont.)

Structure

• 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

7

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

8

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 language-independent 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

9

The Composite design pattern

Structure

• treat multiple individual objects and recursively-composed objects (trees) uniformly– provides extensibility: new components work

wherever old ones do• known uses: file directories, abstract syntax trees

(AST), Java GUI component-container

other versions have been presented

10

The Strategy design pattern

Structure

• 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

11

The Iterator design pattern

Structure

• 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

12

• 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

Other design patterns

13

Design space for GoF patterns

scope: domain over which a pattern applies

purpose: reflects what a pattern does

14

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