2/9/2014

Design Patterns

Design Patterns
Knowledge of design patterns is crucial for any kind of serious software development. Let's learn what they are, what they are
good for, and the names of, and basic ideas behind, a few of the more popular ones.

Patterns
"Each pattern describes a problem which occurs over and over again ... and then describes the core of the
solution to that problem, in such a way that you can use this solution a million times over, without doing it the
same way twice." -- Christopher Alexander

Design Patterns for Object-Oriented Software

Design Patterns are not analysis patterns, are not descriptions of common structures like linked lists, nore are
they detailed application or framework designs. Design Patterns are "descriptions of communicating objects and
classes that are customized to solve a general design problem in a particular context." -- Gamma et al.
Good design patterns help make your software more flexible and reusable.

Why study design patterns

Experts in software architecture and design are highly paid, because they know how to create designs that
are flexible, elegant, and reusable.
You become an expert through experience, reusing solutions that worked for you before.
Patterns describe solutions to design problems that occur over and over again.
Patterns also record design decisions, alternatives, and trade-offs gained from experience.
Once you know the pattern, many design decisions follow.
Knowing patterns helps you get designs right faster.
Knowing the vocabulary surrounding patterns helps communication between designers, and can ease the
documentation effort.

Common themes in design patterns

Design patterns are used by experts to make their designs more flexible and reusable, so in studying them you
tend to see:
decoupling of classes or objects, so something can be changed without changing something else. "Each
http://cs.lmu.edu/~ray/notes/designpatterns/

1/4

2/9/2014

Design Patterns

design pattern lets some aspect of the system vary independently of other aspects, thereby making a system
more robust to a particular kind of change."
elements in a pattern which know how to do one general thing very well and don't know much about anything
else.
efforts to simplify code, to make it more readable, more understandable.
a major emphasis on interfaces ("program to an interface, not to an implementation"), and on the distinction
between types and classes.
a favoring of object composition over class inheritance: too much inheritance leads to an explosion of the
number of classes in a system.

Some real-world examples

Smalltalk's MVC uses Observer to describe the relationship between views and a model, Composite to
describe nested views, and Strategy for the relationship between controllers and views.
In the Java AWT, components are composites, layout managers are strategies, and observers are used to
monitor image loading.
Most application frameworks use factory methods to create the right kind of document.

The 23 patterns from the book

Class

Creational

Structural

Factory Method

Adapter (class)

Interpreter
Template Method

Abstract Factory
Builder
Prototype
Singleton

Adapter (object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Chain of Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Object

Behavioral

Patterns are for Reuse

Each pattern lets you vary some aspect of the system.
Causes of redesign and patterns that address them:
Specifying the class of an object explicitly (Abstract Factory, Factory Method, Prototype)
Hard coding requests (Command, Chain of Responsibility)
Hardware and software platform dependencies (Abstract Factory, Bridge)
Dependence on object representations and implementations (Abstract Factory, Memento, Bridge, Proxy)
Algorithmic dependencies (Strategy, Builder, Iterator, Template Method, Visitor)
Tight coupling (Facade, Mediator, Observer, Command, Abstract Factory, Bridge)
Subclassing to extend functionality (Bridge, Composite, Decorator, Chain of Responsibility, Composite,
http://cs.lmu.edu/~ray/notes/designpatterns/

2/4

2/9/2014

Design Patterns

Strategy)
Inability to alter classes conveniently (Visitor, Decorator, Adapter)

Patterns in the Document Editor Case Study

Composite to represent the structure of the document. Glyphs can be nested
Strategy to allow different formatting algorithms
Decorator to add borders, etc. to the user interface
Abstract Factory to support multiple look-and-feel standards
Bridge to allow it to run on multiple windowing platforms
Command to support undo
Iterator to traverse object structures
Visitor to allow for adding new analytical capabilities

Start by studying the easiest patterns first

Adapter, Decorator, Composite, Observer, Template Method, Factory Method, Abstract Factory, Strategy.

List of the Original 23 Patterns

Purpose

Design Pattern
Abstract Factory

families of product objects

Builder

how a composite object gets created

Creational Factory Method

Structural

Aspect(s) that can vary

subclass of object that is instantiated

Prototype

class of object that is instantiated

Singleton

the sole instance of a class

Adapter

interface to an object

Bridge

implementation of an object

Composite

structure and composition of an object

Decorator

responsibilities of an object without subclassing

Facade

interface to a subsystem

Flyweight

storage costs of objects

Proxy

how an object is accessed; its location

Chain of
Responsibility

object that can fulfill a request

Command

when and how a request is fulfilled

Interpreter

grammar and interpretation of a language

Iterator

how an aggregate's elements are accessed, traversed

Mediator

how and which objects interact with each other

Memento

what private information is stored outside an object, and when

http://cs.lmu.edu/~ray/notes/designpatterns/

3/4

2/9/2014

Design Patterns

Behavioral Observer

number of objects that depend on another object; how the dependent

objects stay up to date

State

states of an object

Strategy

an algorithm

Template
Method

steps of an algorithm

Visitor

operations that can be applied to object(s) without changing their

class(es)

http://cs.lmu.edu/~ray/notes/designpatterns/

4/4