Design patterns

Design Patterns
Introduction and Overview

By,
Abhishek Sagi
Monday 5 December 11

Today
Introduction to Design Patterns :
What are they?

Types of Patterns

Examples : Commonly used patterns

References


Design Patterns
What are they?


Design Patterns
Idea originated from Christopher Wolfgang
Alexander (Austria).

Architect

It was initially applied for architecture for
buildings and towns, But not computer
programming for writing software.


"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 (Architect)
“A Pattern Language”,New York,
Oxford University Press, 1977.


Design Patterns
Even through he was talking about patterns in
buildings and towns, What he says is true about
object-oriented design patterns.

Solutions are expressed in terms of objects and
interfaces instead of walls and doors.

At core both patterns is a solution to a problem
in a context.

Simply, design patterns help a designer to get a
right design faster.


Describes a design pattern as a three-part rule

1.) Description of a context

2.) A problem

3.) A solution

This is modiﬁed for software design patterns which
consists of four parts


Four Essential Parts
Pattern name

A handle to brieﬂy describe the design
problem,but more importantly to provide a common
vocabulary for software designers to use.

Problem

A description of the problem that the design
pattern is intended to solve.


Solution

Describes what elements are required to make up
the design, their relationships and its context.

Consequences

What are the results and trade offs by applying
the design pattern.

Allows comparison between different design
patterns, to see if there is a better ﬁt for the
actual problem.


Design Patterns :
Programming Languages
Aimed towards languages that have language
level support for Object Oriented
Programming
Not exclusively , But it would be easier to apply
with OOP!

Different OOP languages have different
mechanisms for applying patterns.


Types Of Patterns
General description of the type of problem the
pattern addresses

Creational:

Concerned with everything about the
creation of objects

Structural:

Concerned with how classes and objects
are composed to form larger structures


Types Of Patterns
(Continued)
Behavioral

Concerned with algorithms and the
assignment of responsibilities between
objects.


Types Of Patterns (Overview)
Creational: Creational patterns are ones that create objects for you,
rather than having you instantiate objects directly. This gives your program
more ﬂexibility in deciding which objects need to be created for a given
case.

Abstract Factory*: Groups object factories that have a common theme.

Builder constructs: Complex objects by separating construction and
representation.

Factory Method*: Creates objects without specifying the exact class to
create.

Prototype: Creates objects by cloning an existing object.

Singleton*: Restricts object creation for a class to only one instance.


Types Of Patterns (Contd)
Structural Patterns: These concern class and object composition.
They use inheritance to compose interfaces and deﬁne ways to compose
objects to obtain new functionality.

Adapter: Allows classes with incompatible interfaces to work together
by wrapping its own interface around that of an already existing class.

Bridge*: Decouples an abstraction from its implementation so that the
two can vary independently.

Composite: Composes zero-or-more similar objects so that they can be
manipulated as one object.

Decorator: Dynamically adds/overrides behavior in an existing method of
an object.


Facade: Provides a simpliﬁed interface to a large body of code.

Flyweight: Reduces the cost of creating and manipulating a large number
of similar objects.

Proxy: Provides a placeholder for another object to control access,
reduce cost, and reduce complexity.

Behavioral Patterns: Most of these design patterns are speciﬁcally
concerned with communication between objects.

Chain of responsibility: Delegates commands to a chain of processing
objects.

Command: Creates objects which encapsulate actions and parameters.

Interpreter: Implements a specialized language.


Iterator*: Accesses the elements of an object sequentially without
exposing its underlying representation.

Mediator: Allows loose coupling between classes by being the only class
that has detailed knowledge of their methods.

Memento: Provides the ability to restore an object to its previous state
(undo).

Observer: Is a publish/subscribe pattern which allows a number of
observer objects to see an event.

State*: Allows an object to alter its behavior when its internal state
changes.

Strategy: Allows one of a family of algorithms to be selected on-the-ﬂy
at runtime.

Design Pattern
Example 1: The Singleton


Singleton
Creational category of design patterns

Intent: Ensure that a class has only once
instance, And provide global point of access to it.

Motivation: Important for some classes to have
no more than one instance.

Examples:

Console in a game; Logging utility; An
Application Class; A Window Manager.


Singleton
Code Example


Design Pattern
Example 2: State Pattern


State Pattern
Behavioral category of design patterns
Provides behavior to an object so that it can be changed
during runtime.

Very similar to bridge pattern but intention is
different

Bridge is structural :

Hide data from client

client only aware of the handle

State is behavioral :

Provides ﬂexible behavior of owning object and client would be
aware of both owning object and state objects.

State Pattern: Approaches
Application decide
Requires state transition

Implies constraints, And less ﬂexible

states are unaware of each other

States decide
Most ﬂexible approach

States are aware of each other

Implementation dependencies between state code


State creation/destruction:
2 Approaches:
As Needed
States are created on the ﬂy

Destroyed when no longer need - can be expensive

Conserves memory

Preferable where state changes are infrequent

States created in advance (Compile time)
Destroyed only when application terminates - CHEAP!

Memory usage - COSTLY! (all data stored in states are created upfront)

Preferable where state changes are frequent

State Pattern
Code Example


Recommended Books
Design Patterns: Elements of Reusable Object-Oriented Software
Authors: “Gang of four”
Hardback: 416 pages
Publisher: Addison Wesley (14 Mar 1995)
C++
ISBN-10: 0201633612
ISBN-13: 978-0201633610

Head First: Design Patterns
Authors: Several
Paperback: 688 pages
Publisher: O'Reilly Media (25 Oct 2004) Java
ISBN-10: 0596007124
ISBN-13: 978-0596007126


Questions?

Contact: Sharat Chandra (or) Tushar Goswami

Email: abhishek.sagi@ymail.com


References
Design Patterns: Introduction To Design Patterns;
Steven Mead , Senior Programming Lecturer ,
University Of Teesside ; 2010 .

Design Patterns: Elements of Reusable Object-
Oriented Software; Erich Gamma et al; Addison-
Wesley; 1995; 978-0201633610.

http://en.wikipedia.org/wiki/Design_Patterns

Big C++ (2nd edition); Cay Horstmann; Timothy
Budd; John Wiley & Sons; January 2009; 978-
0470383285.

Thank you J


Design patterns

Recommended

More Related Content

What's hot (20)

Viewers also liked (11)

Similar to Design patterns (20)

Recently uploaded (20)

Design patterns