Prophecy Of Design Patterns

Prophecy of Design Patterns

Sep 11th,12th & 13th 2012

By Pradeep Kothiyal

 What are design patterns?
Design Patterns are:
 Recurring solutions to software design problems you find
again and again in real-world application development.
 A general reusable solution to a commonly occurring problem
in software design. - wiki
 It is a description or template for how to solve a problem that
can be used in many different situations.
 Are about design and interaction of objects, as well as
providing a communication platform concerning elegant,
reusable solutions to commonly encountered programming
challenges.
 GoF Patterns are considered the foundation of all design
patterns.

 What are design patterns?
Design Patterns are:
 NOT a finished design that can be transformed directly in
code.
 Object-oriented design patterns shows relationships and
interactions between classes or objects without specifying the
final application classes or objects that are involved.
 Design patterns reside in the domain of modules and
interconnections. At a higher level there are Architectural
patterns[larger in scope], usually describing an overall pattern
followed by an entire system.
 NOT ALL software patterns are design patterns.
Ex: Algorithms solve computational problems rather than
software design problems.

 GoF’s contributions in design pattern
 Gang of Four was a team of four members: Erich Gamma,
Richard Helm, Ralph Johnson and John Vlissides.

(L-R) Ralph, Erich, Richard and John

 GoF’s contributions in design pattern
 Profiles:
 Erich Gamma: Technical Director at Software Technology
Center of OTI at Zurich. Currently working on the IBM
Rational Jazz project
 Richard Helm: With Boston Consulting Group(BCG) in
Sydney, OZ.
 Ralph Johnson: Working on the PatternStoriesWiki and
promoting the OnLineComputerMuseum. Research Associate
Professor in the Department of Computer Science at the
University of Illinois at Urbana-Champaign
 John Vlissides: Was researcher at IBM's T.J. Watson
Research Center.
All 23 patterns has been designed by GoF.
There are more then 300 design patterns in developer
community, which are derived from these 23 patterns.

 Three broad visions:
 Creational Patterns:
are design patterns that deals with Object Creation
Mechanism, trying to create objects in a manner suitable to the
situation. Ex: Abstract Factory, Factory Method etc.
 Structural Patterns:
ease the design by identifying a simple way to realize
relationship between entities. Ex: Façade, Adapter, Proxy etc.
 Behavioral Patterns:
Identify common communication patterns between
objects and realize these patterns, thus increases flexibility in
carrying out this communications. Ex: Observer, Iterator,
Command etc.

 Commonly used patterns:

S No Category Pattern Usage
1 Creational Factory Method*
2 Abstract Factory
3 Singleton
4 Structural Adapter
5 Composite
6 Façade*
7 Behavioral Command
8 Iterator
9 Observer*
10 Strategy

*sample examples

 Factory Method: [Creational Patterns]
Definition:
Define an interface for creating an object, but let
subclasses decide which class to instantiate.
Lets a class defer instantiation to subclasses.
Participants:
Product (Page) : defines the interface of objects the factory
method creates.
ConcreteProduct (SkillsPage, EducationPage, ExperiencePage):
implements the Product interface
Creator (Document) : declares the factory method, which
returns an object of type Product.
Creator may also define a default implementation of the
factory method that returns a default ConcreteProduct object.
may call the factory method to create a Product object.
ConcreteCreator (Report, Resume): overrides the factory
method to return an instance of a ConcreteProduct.

 Factory Method: [Creational Patterns]
UML Notification:

Code Example

 Abstract Factory: [Creational Patterns]
Definition:
Provide an interface for creating families of related or
dependent objects without specifying their concrete classes.
Participants:
AbstractFactory (ContinentFactory): declares an interface for
operations that create abstract products.
ConcreteFactory (AfricaFactory, AmericaFactory): implements
the operations to create concrete product objects.
AbstractProduct (Herbivore, Carnivore): declares an interface
for a type of product object.
Product (Wildebeest, Lion, Bison, Wolf): defines a product
object to be created by the corresponding concrete factory.
implements the AbstractProduct interface.
Client (AnimalWorld): uses interfaces declared by
AbstractFactory and AbstractProduct classes.

 Abstract Factory: [Creational Patterns]
UML Notification:

 Singleton: [Creational Patterns]
Definition:
Ensure a class has only one instance and provide a
global point of access to it.
Participants:
Singleton (LoadBalancer): defines an Instance operation that
lets clients access its unique instance. Instance is a class
operation.
responsible for creating and maintaining its own unique
instance.
UML Notification:

 Adapter: [Structural Patterns]
Definition:
Convert the interface of a class into another interface
clients expect.
Lets classes work together that couldn't otherwise
because of incompatible interfaces.
Participants:
Target (ChemicalCompound): defines the domain-specific
interface that Client uses.
Adapter (Compound): adapts the interface Adaptee to the
Target interface.
Adaptee (ChemicalDatabank): defines an existing interface that
needs adapting.
Client (AdapterApp): collaborates with objects conforming to
the Target interface.

 Adapter: [Structural Patterns]
UML Notification:

 Composite: [Structural Patterns]
Definition:
Compose objects into tree structures to represent part-
whole hierarchies.
Lets clients treat individual objects and compositions
of objects uniformly.
Participants:
Component (DrawingElement): declares the interface for
objects in the composition.
implements default behavior for the interface common to all
classes, as appropriate.
declares an interface for accessing and managing its child
components.
(optional) defines an interface for accessing a component's
parent in the recursive structure, and implements it if that's
appropriate.

Participants:
Leaf (PrimitiveElement): represents leaf objects in the
composition.
A leaf has no children.
defines behavior for primitive objects in the composition.
Composite (CompositeElement): defines behavior for
components having children.
stores child components.
implements child-related operations in the Component
interface.
Client (CompositeApp):manipulates objects in the composition
through the Component interface.

UML Notification:

 Facade: [Structural Patterns]
Definition:
Provide a unified interface to a set of interfaces in a
subsystem.
defines a higher-level interface that makes the
subsystem easier to use.
Participants:
Façade (MortgageApplication): knows which subsystem classes
are responsible for a request.
delegates client requests to appropriate subsystem objects
Subsystem classes (Bank,Credit,Loan) implement subsystem
functionality.
handle work assigned by the Facade object.
have no knowledge of the facade and keep no reference to it

 Facade: [Structural Patterns]
UML Notification:

Code Example

 Command: [Behavioral Patterns]
Definition:
Encapsulate a request as an object.
thereby letting parameterize clients with different
requests, queue or log requests, and support undoable operations
Participants:
Command (Command): declares an interface for executing an
operation.
ConcreteCommand (CalculatorCommand): defines a binding
between a Receiver object and an action.
implements Execute by invoking the corresponding operation(s) on
Receiver.
Client (CommandApp) : creates a ConcreteCommand object and
sets its receiver .
Invoker (User): asks the command to carry out the request.
Receiver (Calculator): knows how to perform the operations
associated with carrying out the request.

 Command: [Behavioral Patterns]
UML Notification:

 Iterator: [Behavioral Patterns]
Definition:
Provide a way to access the elements of an aggregate
object sequentially without exposing its underlying
representation.
Participants:
Iterator (AbstractIterator): defines an interface for accessing
and traversing elements.
ConcreteIterator (Iterator): implements the Iterator interface.
keeps track of the current position in the traversal of the
aggregate.
Aggregate (AbstractCollection): defines an interface for
creating an Iterator object.
ConcreteAggregate (Collection): implements the Iterator
creation interface to return an instance of the proper
ConcreteIterator.

 Iterator: [Behavioral Patterns]
UML Notification:

 Observer: [Behavioral Patterns]
Definition:
Define a one-to-many dependency between objects so
that when one object changes state, all its dependents are
notified and updated automatically.
Participants:
Subject (Stock): knows its observers. Any number of Observer
objects may observe a subject provides an interface for
attaching and detaching Observer objects.
ConcreteSubject (IBM): stores state of interest to
ConcreteObserver.
sends a notification to its observers when its state changes.
Observer (Iinvestor): defines an updating interface for objects
that should be notified of changes in a subject.
ConcreteObserver (Investor): maintains a reference to a
ConcreteSubject object.

Participants:
ConcreteObserver (Investor): stores state that should stay
consistent with the subject's.
implements the Observer updating interface to keep its state
consistent with the subject's.

UML Notification:

Code Example

 Strategy: [Behavioral Patterns]
Definition:
Define a family of algorithms, encapsulate each one,
and make them interchangeable.
Lets the algorithm vary independently from clients that use it.
Participants:
Strategy (SortStrategy): declares an interface common to all
supported algorithms. Context uses this interface to call the
algorithm defined by a ConcreteStrategy.
ConcreteStrategy (QuickSort, ShellSort, MergeSort) :
implements the algorithm using the Strategy interface.
Context (SortedList) : is configured with a ConcreteStrategy
object .
maintains a reference to a Strategy object.
may define an interface that lets Strategy access its data.

 Strategy: [Behavioral Patterns]
UML Notification:

 Comparison tally of design patterns:

1 Creational Abstract Factory
2 Builder
3 Factory Method
4 Prototype
5 Singleton
6 Structural Adapter
7 Bridge
8 Composite
9 Decorator
10 Facade
11 Flyweight
12 Proxy

 Comparison tally of design patterns:

13 Behavioral Chain of Responsibility
14 Command

15 Interpretor
16 Iterator
17 Mediator
18 Memento
19 Observer
20 State
21 Strategy
22 Template Method
23 Visitor

 Observer Design Pattern: Optimizing Performance

Requirements:
Each Order is associated with one Customer and one SalesPerson.
Each Order includes various OrderDetail transactions. [Relationship One to Many]


Requirements:
user wants to view Report or Dashboard including total sales amount for each product, total
sold amount each sales person sells, and total payment amount each customer pays.


Solution:
Making sum once, storing it in the database.
Customer: Add field “TotalPaymentAmount”
Product: Add field “TotalSalesAmount”
SalesPerson: Add field “TotalSoldAmount”


Solution:
when SalesPerson updates Order data, system updates 3 total fields too. This gives a
hint about Subscriber-Publisher Model(Observer Pattern).


Observer Design Pattern:
defines a one-to-many dependency between objects so that when one object changes state,
all its dependents are notified and updated automatically.

 Design Pattern: Real world challenges
• What kind of evidence do we need to have to know that a pattern
is of general use in design?
• What are the barriers for making a pattern language a useful tool
for the broader community of educators and educational
researchers?
• As the pattern approach becomes more successful, how can we
ensure that pattern authors build on each other’s work, fostering a
culture of knowledge accumulation?
• How is the pattern approach related to other means of knowledge
sharing?
Ref: http://patternlanguagenetwork.myxwiki.org/xwiki/bin/view/Groups.CAL09/

Prophecy Of Design Patterns

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Prophecy Of Design Patterns (20)

Prophecy Of Design Patterns