PDF Archive

Easily share your PDF documents with your contacts, on the Web and Social Networks.

Share a file Manage my documents Convert Recover PDF Search Help Contact



c .pdf



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 1058 times.
File size: 3.1 MB (58 pages).
Privacy: public file




Download original PDF file









Document preview


Design Pattern
 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
twice.”

Design Pattern
 In software engineering, a design pattern is a general

reusable solution to a commonly occurring problem in
software design.
 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.

Design Pattern

Designer

How Patterns are used?
 Design Problem.
 Solution.

Programmer

 Implementation details.

Reduce gap
Design

Implementation

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.

Classifications
 Structural
 Creational
 Behavioral

Structural
 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
extension.








Decorator
Proxy
Bridge
Composite
Flyweight
Adapter
Facade

Purpose of Structural Patterns
 Decorator


Add new functionality dynamically to existing objects, or remove it

 Proxy



Control access to an object
Create expensive objects on demand

 Bridge




Enable development of the interface and implementation of a
component a proceed independently
Select or switch implementations at runtime

 Adapter


Match otherwise incompatible interfaces

Purpose of Structural Patterns
 Flyweight


Reduce the cost of working with large numbers of very small
objects

 Facade




Reorganize a system with many subsystems into identifiable
layers with single entry point
Simplify the interface to a complex subsystem

 Composite


Treat single objects and composite objects in the same way

Creational Patterns
 The creational patterns aim to separate a system from

how its objects are created, composed, and
represented.
 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
put together.

Creational Patterns
 Prototype


The Prototype pattern creates new objects by cloning one of a
few stored prototypes.

 Factory


The Factory Method pattern is a way of creating objects, but
letting subclasses decide exactly which class to instantiate.

 Singleton


Ensures that there is only one instance of a class, and that
there is a global access point to that object.

Creational Patterns
 Builder


separates the specification of a complex object from its actual
construction. The same construction process can create
different representations.

Behavioral Patterns
 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
maintain.
 The behavioral patterns capture ways of expressing the
division of operations between classes and optimize
how the communication should be handled

Behavioral Patterns
 Strategy




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
result.

Behavioral Patterns
 State Pattern


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
hierarchy.

Behavioral Patterns
 Template Methods


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.

Behavioral Patterns
 Command




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
operations
 Redo and Undo functionality

Behavioral Patterns
 support communication between objects while letting

them keep their independence and, in some cases,
their anonymity.
 Iterator


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.

Behavioral Patterns
 Mediator


Enable objects to communicate without knowing each other’s
identities. It also encapsulates a protocol that objects can
follow.

 Observer


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
Design Patterns

Template for discussion
 Non-software example.
 Pattern intent.
 Software counterpart example.

Non-software examples are derived from
paper
& 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
subsystem.

Facade (Software counterpart)

Flyweight (Non software example)
Use sharing to
support large
numbers of finegrained objects
efficiently

Flyweight (Software counterpart)

Memory

Chain of Responsibility (Non software
example)
Chain the
receiving objects
and pass the
request along the
chain until an
object handles it.

Chain of Responsibility (Software
counterpart)

Interne
t
Login
page

Password
checking

Balance
statement

Memento (Non software example)
Externalize
object’s state so
that object can be
restored to this
state later.

Memento (Software counterpart)

Observer (Non software example)
When an object
changes its
state,
all its
dependants
are notified.

Observer (Software counterpart)

Internet

Cricinfo
Server

Adapter (Non software example)
Convert the
interface of a
class into another
Interface clients
expect.

Adapter (Software counterpart)
Java module

Java Native
Interface
(JNI)

C++ module

Builder (Non software example)
Separate the construction
process of a complex object
from its representation so
that the same construction
Process can create different
representations.

Builder (Software counterpart)
Compiler process
Lexical
analysis

Syntax
analysis

Semantic
analysis

Intermediate
code

Interpret
ation

Java
Parser

Semantic
analysis

Java byte
code

JVM

Python
Parser

Semantic
analysis

Python byte
code

PVM

Java Compiler
Java
Lexer

Python Compiler
Python
Lexer

Iterator (Non software example)
Provide a way to
access the
elements of a set
sequentially.

Iterator (Software counterpart)

Interpreter (Non software
example)
Interpreter interprets
the sentences in a
language based
on its grammar.

Interpreter (Software counterpart)
In Gtalk/Yahoo messengers
:-) is interpreted as 
:-( is interpreted as 

Proxy (Non software example)
Provide a surrogate or
placeholder for
another object to
control access to it.

Proxy (Software counterpart)

Strategy (Non software example)

A Strategy defines a set of algorithms that can be
used interchangeably.

Strategy (Software counterpart)
Multiple
interchangeable
weapons available
to
attack an enemy.

Mediator (Non software example)
Loose coupling
between colleague
objects is achieved by
having colleagues
communicate with the
Mediator, rather than
one another.

Mediator (Software counterpart)
Gtalk
Server

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
programming
 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

Observer Pattern
 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
controls it
 The Observers rely on the subject to tell them when its
state changes

Observer Pattern Class Diagram


Related documents


saunit7
b
oomdunit6
c
saunit4
oomdunit8


Related keywords