Original filename: c.pdf
This PDF 1.5 document has been generated by Microsoft® Office PowerPoint® 2007, and has been sent on pdf-archive.com on 16/06/2011 at 04:51, from IP address 124.106.x.x.
The current document download page has been viewed 970 times.
File size: 3.1 MB (58 pages).
Privacy: public file
Download original PDF file
It is a formal way of documenting a solution to a
design problem in a particular field of expertise.
Introduced by Architect Christopher Alexander in the
field of Architecture
“ The elements of this language are entities called
patterns. Each pattern describes a problem that
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
In software engineering, a design pattern is a general
reusable solution to a commonly occurring problem in
A design pattern is not a finished design that can be
transformed directly into code.
It is a description or template for how to solve a
problem that can be used in many different situations.
How Patterns are used?
Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design patterns: elements of reusable
object-oriented software. 1995.
Buschmann, F., Meunier, R., Rohnert, H., Sommerlad, P., Stal, M.: Pattern-oriented
software architecture: a system of patterns. 2002.
Structural patterns are concerned with how classes and
objects are composed to form larger structures.
Structural patterns can be employed while a system is
being designed, or later on during maintenance and
Purpose of Structural Patterns
Add new functionality dynamically to existing objects, or remove it
Control access to an object
Create expensive objects on demand
Enable development of the interface and implementation of a
component a proceed independently
Select or switch implementations at runtime
Match otherwise incompatible interfaces
Purpose of Structural Patterns
Reduce the cost of working with large numbers of very small
Reorganize a system with many subsystems into identifiable
layers with single entry point
Simplify the interface to a complex subsystem
Treat single objects and composite objects in the same way
The creational patterns aim to separate a system from
how its objects are created, composed, and
They increase the system’s flexibility in terms of the
what, who, how, and when of object creation.
Creational patterns encapsulate the knowledge about
which classes a system uses, but they hide the details
of how the instances of these classes are created and
The Prototype pattern creates new objects by cloning one of a
few stored prototypes.
The Factory Method pattern is a way of creating objects, but
letting subclasses decide exactly which class to instantiate.
Ensures that there is only one instance of a class, and that
there is a global access point to that object.
separates the specification of a complex object from its actual
construction. The same construction process can create
Behavioral patterns are concerned with algorithms and
communication between them.
The operations that make up a single algorithm might
be split up between different classes, making a
complex arrangement that is difficult to manage and
The behavioral patterns capture ways of expressing the
division of operations between classes and optimize
how the communication should be handled
The Strategy pattern involves removing an algorithm from its
host class and putting it in a separate class.
There may be different algorithms (strategies) that are
applicable for a given problem. If the algorithms are all kept in
the host, messy code with lots of conditional statements will
can be seen as a dynamic version of the Strategy pattern.
When the state inside an object changes, it can change its
behavior by switching to a set of different operations. This is
achieved by an object variable changing its subclass, within a
enables algorithms to defer certain steps to subclasses. The
structure of the algorithm does not change, but small welldefined parts of its operation are handled elsewhere.
Chain of Responsibility
works with a list of Handler objects that have limitations on
the nature of the requests they can deal with. If an object
cannot handle a request, it passes it on to the next object in
the chain. At the end of the chain, there can be either default
or exceptional behavior.
The Command pattern creates distance between the client
that requests an operation and the object that can perform it.
This pattern is particularly versatile.
It can support:
Sending requests to different receivers
Queuing, logging, and rejecting requests
Composing higher-level transactions from primitive
Redo and Undo functionality
support communication between objects while letting
them keep their independence and, in some cases,
provides a way of accessing elements of a collection
sequentially, without knowing how the collection is
structured. As an extension, the pattern allows for filtering
elements in a variety of ways as they are generated.
Enable objects to communicate without knowing each other’s
identities. It also encapsulates a protocol that objects can
defines a relationship between objects so that when one
changes its state, all the others are notified accordingly. There
is usually an identifiable single publisher of new state, and
many subscribers who wish to receive it.
Some examples of
Template for discussion
Software counterpart example.
Non-software examples are derived from
& PPT – “Non-software examples of software
design patterns” (OOPSLA 97).
Facade (Non software example)
Provide a unified
interface to a set
of interfaces in a
Facade (Software counterpart)
Flyweight (Non software example)
Use sharing to
numbers of finegrained objects
Flyweight (Software counterpart)
Chain of Responsibility (Non software
and pass the
request along the
chain until an
object handles it.
Chain of Responsibility (Software
Memento (Non software example)
object’s state so
that object can be
restored to this
Memento (Software counterpart)
Observer (Non software example)
When an object
Observer (Software counterpart)
Adapter (Non software example)
interface of a
class into another
Adapter (Software counterpart)
Builder (Non software example)
Separate the construction
process of a complex object
from its representation so
that the same construction
Process can create different
Builder (Software counterpart)
Iterator (Non software example)
Provide a way to
elements of a set
Iterator (Software counterpart)
Interpreter (Non software
the sentences in a
on its grammar.
Interpreter (Software counterpart)
In Gtalk/Yahoo messengers
:-) is interpreted as
:-( is interpreted as
Proxy (Non software example)
Provide a surrogate or
another object to
control access to it.
Proxy (Software counterpart)
Strategy (Non software example)
A Strategy defines a set of algorithms that can be
Strategy (Software counterpart)
attack an enemy.
Mediator (Non software example)
objects is achieved by
communicate with the
Mediator, rather than
Mediator (Software counterpart)
The “gang of four” (GoF)
Erich Gamma, Richard Helm, Ralph Johnson
& John Vlissides (Addison-Wesley, 1995)
Design Patterns book catalogs 23 different patterns as solutions
to different classes of problems, in C++ & Smalltalk
The problems and solutions are broadly applicable, used by
many people over many years
What design pattern did we discover with the Undo problem?
Why is it useful to learn about this pattern?
Patterns suggest opportunities for reuse in analysis, design and
GOF presents each pattern in a structured format
What do you think of this format? Pros and cons?
Elements of Design Patterns
Design patterns have 4 essential elements:
Pattern name: increases vocabulary of designers
Problem: intent, context, when to apply
Solution: UML-like structure, abstract code
Consequences: results and tradeoffs
Subject + Observer = Observer Pattern
The Observer Pattern defines a one-to-many
relationship between a set of objects. When a state of
one object changes, all of its dependents are notified.
Depending on the style of notification, the observer
may also be updated with the new values.
The Subject is the object that contains the state and
The Observers rely on the subject to tell them when its
Observer Pattern Class Diagram