4. 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.
Monday 5 December 11
5. "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.
Monday 5 December 11
6. 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.
Monday 5 December 11
7. Describes a design pattern as a three-part rule
1.) Description of a context
2.) A problem
3.) A solution
This is modified for software design patterns which
consists of four parts
Monday 5 December 11
8. Four Essential Parts
Pattern name
A handle to briefly 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.
Monday 5 December 11
9. 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 fit for the
actual problem.
Monday 5 December 11
10. 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.
Monday 5 December 11
11. 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
Monday 5 December 11
12. Types Of Patterns
(Continued)
Behavioral
Concerned with algorithms and the
assignment of responsibilities between
objects.
Monday 5 December 11
13. 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 flexibility 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.
Monday 5 December 11
14. Types Of Patterns (Contd)
Structural Patterns: These concern class and object composition.
They use inheritance to compose interfaces and define 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.
Monday 5 December 11
15. Types Of Patterns (Contd)
Facade: Provides a simplified 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 specifically
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.
Monday 5 December 11
16. Types Of Patterns (Contd)
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-fly
at runtime.
Monday 5 December 11
17. Design Pattern
Example 1: The Singleton
Monday 5 December 11
18. 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.
Monday 5 December 11
20. Design Pattern
Example 2: State Pattern
Monday 5 December 11
21. 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 flexible behavior of owning object and client would be
aware of both owning object and state objects.
Monday 5 December 11
22. State Pattern: Approaches
Application decide
Requires state transition
Implies constraints, And less flexible
states are unaware of each other
States decide
Most flexible approach
States are aware of each other
Implementation dependencies between state code
Monday 5 December 11
23. State creation/destruction:
2 Approaches:
As Needed
States are created on the fly
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
Monday 5 December 11
27. 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.
Monday 5 December 11