Design Patterns

1
 Overview
 Books
 Design Patterns – Basics
 Structural Design Patterns
 Behavioral Design Patterns

2
Books
 Design Patterns : Elements of Reusable Object-Oriented Software
(1995)
 (The-Gang-of-Four Book)
 The-Gang-of-Four (GoF) - Gamma, Helm, Johnson , Vlissides
 Analysis Patterns - Reusable Object Models (1997)
 Martin Fowler

3
Design Patterns
“Each pattern describes
a problem which occurs over and over again in our environment,
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 ever doing it the same way twice”.
--- Christopher Alexander, 1977

This was in describing patterns in buildings and towns.

In SE, design patterns are in terms of objects and interfaces, not
walls and doors.

The manner in which a collection of interacting objects collaborate to accomplish a

specific task or provide some specific functionality.

4
4 Essential Elements of Design Patterns

 Name: identifies a pattern

 Problem: describes when to apply the pattern in terms of the
problem and context
 Solution: describes elements that make up the design, their
relationships, responsibilities, and collaborations
 Consequences: results and trade-offs of applying the pattern

5
How to Describe Design Patterns more fully
This is critical because the information has to be conveyed to peer developers in
order for them to be able to evaluate, select and utilize patterns.

 A format for design patterns

 Pattern Name and Classification
 Intent
 Also Known As
 Motivation
 Applicability
 Structure
 Participants
 Collaborations
 Consequences
 Implementation
 Sample Code
 Known Uses
 Related Patterns
6
Organizing Design Patterns
 By Purpose (reflects what a pattern does):
 Creational Patterns
 Structural Patterns
 Behavioral Patterns

 By Scope: specifies whether the pattern applies primarily to

 classes or to
 objects.

7
Design Patterns Space
Purpose
Creational Structural Behavioral
Interpreter
Class Factory Method Adapter
Scope Template

Object Abstract Factory Adapter Chain of

Builder Bridge Responsibility
Prototype Composite Command
Singleton Decorator Iterator
Façade Mediator
Flyweight Memento
Proxy Observer
State
Strategy
Visitor

8
What are creational patterns?
 Design patterns that deal with object creation
mechanisms, trying to create objects in a manner
suitable to the situation
 Make a system independent of the way in which
objects are created, composed and represented
 Recurring themes:
 Encapsulate knowledge about which concrete classes the
system uses (so we can change them easily later)
 Hide how instances of these classes are created and put
together (so we can change it easily later)
Benefits of creational patterns
 Creational patterns let you program to an interface
defined by an abstract class
 That lets you configure a system with “product”
objects that vary widely in structure and functionality
 Example: GUI systems
 InterViews GUI class library
 Multiple look-and-feels
 Abstract Factories for different screen components
Benefits of creational patterns
 Generic instantiation – Objects are instantiated
without having to identify a specific class type in
client code (Abstract Factory, Factory)
 Simplicity – Make instantiation easier: callers do not
have to write long complex code to instantiate and
set up an object (Builder, Prototype pattern)
 Creation constraints – Creational patterns can put
bounds on who can create objects, how they are
created, and when they are created
Abstract Factory: An Example
 PIM system
 Manage addresses and phone numbers
 You hard-coded it for US data
 At some point, you wanted to extend it to incorporate any
address / phone number
 So you subclassed
 DutchAddress, JapanesePhoneNumber, etc.
 But now, how do you create them?
Abstract Factory: Overview
 Intent
 Provide an interface for creating families of related or
dependent objects without specifying their concrete
classes
 Analogous to a pasta maker
Your code is the pasta maker
Different disks create different pasta shapes:
these are the factories
All disks have certain properties in common
so that they will work with the pasta maker
All pastas have certain characteristics in
common that are inherited from the generic
“Pasta” object
Abstract Factory: Participants
 AbstractFactory
Declares an interface for operations that
create abstract products

 ConcreteFactory
Implements the operations to create
concrete product objects: usually
instantiated as a Singleton

 AbstractProduct
Declares an interface for a type of
product object; Concrete Factories
produce the concrete products

 ConcreteProduct
Defines a product object to be created
by the corresponding concrete factory
Abstract Factory: Applicability
 Use Abstract Factory when:
 A system should be independent of how its products are
created, composed, and represented
 A system should be configured with one of multiple
families of products
 You want to provide a class library of products, and you
want to reveal just their interfaces, not their
implementations
Abstract Factory: Consequences
 Good:
 Isolates concrete classes
 All manipulation on client-side done through abstract interfaces
 Makes exchanging product families easy
 Just change the ConcreteFactory
 Enforces consistency among products
 Bad
 Supporting new kinds of products is difficult
 Have to reprogram Abstract Factory and all subclasses
 But it’s not so bad in dynamically typed languages
Abstract Factory: Implementation
 Usually should be a Singleton
 Define a Factory Method (GoF) in AbstractFactory –
ConcreteFactory then specifies its products by
overriding the factory for each
public class USAddressFactory implements AddressFactory{
public Address createAddress(){
return new USAddress();
}

public PhoneNumber createPhoneNumber(){

return new USPhoneNumber();
}
}
 Maybe use Prototype pattern in dynamically typed
languages (e.g. Smalltalk) to simplify creation
Creational Patterns

18
Structural Patterns
 Composite
 Adapter
 Façade
 Proxy

19
Structural Patterns - Façade
Intent
Provide a unified interface to a set of interfaces in a subsystem.
Façade defines a higher-level interface that makes the subsystem
easier to use.

Applicability
 Provides a simple interface to a complex subsystem.
 Decouples the details of a subsystem from clients and other
subsystems.
 Provides a layered approach to subsystems.

20
Structural Patterns - Façade
Class Diagram
subsystem

Facade

21
Structural Patterns - Façade
Participants
 Façade
 Knows which classes are responsible for each request.
 Delegates client requests to appropriate objects.
 Subsystem classes
 Implement subsystem functionality.
 Handle work assigned by the Façade object.
 Have no knowledge of the façade.

Collaborations
 Clients communicate with the subsystem sending requests to the Façade.
 Reduces the number of classes the client deals with.
 Simplifies the subsystem.
 Clients do not have to access subsystem objects directly.
22
Behavioral Patterns
 Observer
 Strategy
 Command
 State
 Visitor

23
Behavioral Patterns - Sorting Example
 Requirement: we want to sort a list of integers using
different sorting algorithms, e.g. quick sort, selection sort,
insertion sort, etc.
 E.g., {3, 5, 6, 2, 44, 67, 1, 344, ... }
 {1, 2, 3, 5, 6, 44, 67, 344, ... }

 One way to solve this problem is to write a function for each

sorting algorithm, e.g.
 quicksort(int[] in, int[] res)
 insertionsort(int[] in, int[] res)
 mergesort(int[] in, int[] res)
 A better way is to use the Strategy pattern 24
 Behavioral Patterns - Strategy Pattern
Main() How is stdRec implemented?
Main {…
stdRec.SetSortStr(sortStrInfo);
Main() stdRec.Sort()}

How is –sortStrategy implemented?

stdRec
-sortStrategy
SortedList SortStrategy
-list: ArrayList
Sort(list:ArrayList)
SetSortStr(sortStr:SortStrategy)
Sort()

Sort()
{sortStrategy.Sort(list)}

QuickSort InsertionSort MergeSort

Sort(list:ArrayList) Sort(list:ArrayList) Sort(list:ArrayList)

25
How to Select & Use Design Patterns
How to Select (> 20 in the book, and still growing … fast?, more on Internet)
 Scan Intent Sections
 Study How Patterns Interrelate
 Study Patterns of Like Purpose
 Examine a Cause of Redesign
 Consider What Should Be Variable in Your Design
How to Use
 Read the pattern once through for an overview: appears trivial, but not
 Go back and study the structure, participants, and collaborations sections
 Look at Sample Code: concrete example of pattern in code
 Choose names for pattern participants
 Define the classes
 Define application specific names for operations in the pattern
 Implement the operations to carry out the responsibilities and collaborations in
the pattern
26
Points to Ponder
 List as many design patterns as you can think of in the Model-View-
Controller (MVC).
 How many design patterns can exist? In the order of tens?
hundreds? or thousands? Justify your reasoning.
 What would be the major differences between design patterns and
architectural patterns?
 What style of architecture is closest to the Observer pattern in the
manner objects interact with each other?
 Map the Observer pattern into the Java Event Model.
 What are the essential tradeoffs between
1) Observers query a Subject periodically and
2) using the Observer pattern?

27