This session covers details on What is a design pattern, Why Design pattern, When to use design pattern, Types of Design Pattern....etc.

1. 1
Structural
Patterns
SolutionsProblems
Creational
Patterns
Behavioral
Pattern
Why ?
LET US UNDERSTAND DESIGN PATTERNS
Rabinarayan Biswal
Mindfire Solutions
14/05/2013
When ?
How ?

2. AGENDA
A brief history
What is design
pattern
When to use
design Pattern ?
Introduct
ion
Classification of
Design Patterns
Understanding
different
patterns
How to use
different
patterns ?
Overview
Data Tier
Middle Tier
Presentation Tier
MVC
Detailed
Study

3. A BRIEF HISTORY
Christopher Alexander Kent Beck Ward Cunningham
- Patterns originated as an architectural concept by Christopher Alexander (1977/79).
- In 1987 Kent Beck (creator of Extreme Programming and TDD) and Ward Cunningham (contributor to
Extreme Programming) began experimenting with the idea of applying patterns to programming and
presented their results at the OOPSLA conference that year

4. GANG OF FOUR
Erich Gamma Ralph Johnson John Vlissides Richard Helm
- Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable
Object-Oriented Software was published in 1994 by the so-called "Gang of Four" (GoF)
- GoF established 23 patterns classified into 3 types – Creational, Structural and Behavioral

5. WHAT IS DESIGN PATTERN ?
solutionsReusable ProblemsCommonly
occurring DesignSoftware
- In software engineering, a design pattern is a general reusable solution to a commonly occurring problem
within a given context in software design - Wikipedia
- It is a description for how to solve a problem that can be used in many different situations

6. WHEN DESIGN PATTERN ?
You can consider not using any design pattern in following cases –
- The application being built will not change in future, the code accurately captures all requirements and
there are no planned enhancements on new features (the application you are building is the first and
last release )
- Your application‟s requirement is unique . No software engineer has ever built anything like your
application 
- There is plenty of time to prototype your new design ideas . No proof-of-concept is required 
- Everyone one your team has worked together for 20 years or so . You all posses a common set of design
vocabulary, so you don‟t need to learn someone else‟ 
If you don’t fall into any of the above categories – Use Design
Pattern 

7. THE STORY OF LIGHT, SWITCH & FAN
Fan Fancy Switch Bulb Normal Switch

8. BENEFITS OF USING DESIGN PATTERN
- speed up the development process by providing tested, proven development paradigms .
- Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also
improves code readability for coders and architects who are familiar with the patterns.
- Design patterns provide general solutions, documented in a format that doesn't require specifics tied to
a particular problem.
- In addition, patterns allow developers to communicate using well-known, well understood names for
software interactions. Common design patterns can be improved over time, making them more robust
than ad-hoc designs
- A standard solution to a common programming problem enable large scale reuse of S/W

9. TYPES OF DESIGN PATTERNS
Creational •Object creation
Structural
•Build large, complex
objects
Behavioral
•Play with algorithms and
relationship with objects

10. DESIGN PATTERNS
Creational
• Factory Method
• Abstract Factory Method
• Singleton
• Builder
• Prototype
Structural
• Adaptor
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy
Behavioral
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template
• Visitor

11. USAGE
High
Factory
Abstract
Factory
Façade
Iterator
Observer
Medium High
Singleton
Adapter
Composite
Proxy
Command
Strategy
Medium
Prototype
Bridge
Decorator
State
Template
Medium Low
Builder
Chain of
Responsibi
lity
Mediator
Low
Flyweight
Interpreter
Memento
Visitor

12. Creational
Pattern
creational design patterns are design patterns that deal with object creation mechanisms, trying to create
objects in a manner suitable to the situation. The basic form of object creation could result in design
problems or added complexity to the design. Creational design patterns solve this problem by controlling
the object creation.

13. FACTORY DESIGN PATTERN
- This pattern is used to create concrete class instances without specifying the exact class type.
- Define an interface for creating an object, but let the subclasses decide which class to instantiate. The Factory
method lets a class defer instantiation to subclasses .
- Logical model

14. FACTORY PATTERN - A REAL WORLD EXAMPLE
Document
Resume Report Presentation

15. FACTORY PATTERN - UML

16. FACTORY PATTERN – HOW ?
- If you have an inheritance hierarchy that exercises polymorphism, consider adding a polymorphic
creation capability by defining a static factory method in the base class.
- Design the arguments to the factory method. What qualities or characteristics are necessary and
sufficient to identify the correct derived class to instantiate?
- Consider designing an internal “object pool” that will allow objects to be reused instead of created from
scratch.
- Consider making all constructors private or protected.

17. FACTORY PATTERN IN .NET
- IDbCommand.CreateParameter
- Convert.ToBoolean
- WebRequest: HttpWebRequest, FtpWebRequest
- ASP.NET Runtime

18. FACTORY PATTERN – WHEN ?
Do we need to have derived classes figure out what to instantiate
and decouple client from instantiated class ?

19. Structural Pattern
structural design patterns are design patterns that ease the design by identifying a simple way to realize
relationships between entities.

20. FAÇADE DESIGN PATTERN
- Used to provide a simpler interface into a more complicated portion of code.
- A facade can make a software library easier to use and understand, since the facade has convenient methods for
common tasks
- A facade can make code that uses the library more readable, for the same reason
- A facade can reduce dependencies of outside code on the inner workings of a library, since most code uses the
facade, thus allowing more flexibility in developing the system
- A facade can wrap a poorly-designed collection of APIs with a single well-designed API
- The Facade however, can itself become too complex for a huge subsystem. Also it's a good idea to actually have
an abstract Facade over the Facade. One of the most common and successful examples is using this pattern
through a webservice, making the webservice acting as the Facade or the interface to many different dll's each
representing a subsystem.

21. FAÇADE - UML

22. FAÇADE – A REAL WORLD EXAMPLE
Marriage
Decoration
Food
Procession

23. FAÇADE DESIGN PATTERN – HOW ?
- Identify a simpler, unified interface for the subsystem or component.
- Design a „wrapper‟ class that encapsulates the subsystem.
- The facade/wrapper captures the complexity and collaborations of the component, and delegates to the
appropriate methods.
- The client uses (is coupled to) the Facade only.
- Consider whether additional Facades would add value.

24. FAÇADE DESIGN PATTERN – WHEN ?
Do we want simplify, beautify or OO-fy an existing class or subsystem ?

25. COMPOSITE DESIGN PATTERN
- Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual
objects and compositions of objects uniformly.
- Recursive composition
- “Directories contain entries, each of which could be a directory.”
- 1-to-many “has a” up the “is a” hierarchy

26. COMPOSITE PATTERN – UML

27. COMPOSITE – A REAL WORLD EXAMPLE
Category
Food
Diary
Milk
Yogurt
cheese
Non-Veg
Fish
Chicken
Veg
Potato
Onion
Sweets
Candy
Ice cream
Electronics
Audio
Digital

28. COMPOSITE PATTERN – HOW ?
- Ensure that your problem is about representing “whole-part” hierarchical relationships.
- Consider the heuristic, “Containers that contain containees, each of which could be a container.” For
example, “Assemblies that contain components, each of which could be an assembly.” Divide your
domain concepts into container classes, and containee classes.
- Create a “lowest common denominator” interface that makes your containers and containees
interchangeable. It should specify the behavior that needs to be exercised uniformly across all containee
and container objects.
- All container and containee classes declare an “is a” relationship to the interface.
- All container classes declare a one-to-many “has a” relationship to the interface.
- Container classes leverage polymorphism to delegate to their containee objects.
- Child management methods [e.g. addChild(), removeChild()] should normally be defined in the
Composite class. Unfortunately, the desire to treat Leaf and Composite objects uniformly may require
that these methods be promoted to the abstract Component class. See the Gang of Four for a
discussion of these “safety” versus “transparency” trade-offs.

29. COMPOSITE PATTERN – WHEN ?
Do we have units and groups and want to treat them the same way ?

30. Behavioral
Pattern
behavioral design patterns are design patterns that identify common communication patterns between
objects and realize these patterns. By doing so, these patterns increase flexibility in carrying out this
communication.

31. OBSERVER DESIGN PATTERN
- Define a one-to-many dependency between objects so that when one object changes state, all its
dependents are notified and updated automatically.
- You should use the pattern in the following cases:
- You have a publisher/subscriber model.
- Objects need to be notified of a change in another objects.
- You need that the object that notify its state change would not know about its subscribers.

32. OBSERVER PATTERN–A REAL WORLD EXAMPLE
Stock
Investor
UI

33. OBSERVER PATTERN - UML

34. OBSERVER PATTERN – HOW ?
- Differentiate between the core (or independent) functionality and the optional (or dependent)
functionality.
- Model the independent functionality with a “subject” abstraction.
- Model the dependent functionality with an “observer” hierarchy.
- The Subject is coupled only to the Observer base class.
- The client configures the number and type of Observers.
- Observers register themselves with the Subject.
- The Subject broadcasts events to all registered Observers.
- The Subject may “push” information at the Observers, or, the Observers may “pull” the information they
need from the Subject.

35. OBSERVER PATTERN IN .NET
Event Driven Programming

36. OBSERVER PATTERN – WHEN ?
Do various entities need to know about events that have occurred?
How to keep dependent object up-to-date.

37. STRATEGY DESIGN PATTERN
- The Strategy design pattern allows you to use multiple algorithms interchangeably.
- Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the
algorithm vary independently from the clients that use it.
- Capture the abstraction in an interface, bury implementation details in derived classes.

38. STRATEGY PATTERN- A REAL WORLD EXAMPLE
Sorting
Merge
Sort
Shell
Sort
Quick
Sort

39. STRATEGY DESIGN PATTERN - UML

40. STRATEGY PATTERN – HOW ?
- Identify an algorithm (i.e. a behavior) that the client would prefer to access through a “flex point”.
- Specify the signature for that algorithm in an interface.
- Bury the alternative implementation details in derived classes.
- Clients of the algorithm couple themselves to the interface.

41. STRATEGY PATTERN IN .NET
Membership Providers
Role Providers
Site Map Providers
Session State Providers
Profile Providers
Web Event Providers
Web Parts Personalization Providers

42. STRATEGY PATTERN – WHEN ?
Do we have a varying rule or algorithm ?

43. MVC
MVC
Observer
(Behavioral)
Composite
(Structural)
Factory
(Creational)
Strategy
(Behavioral)

44. PATTERNS IN MVC
Observer (Behavioral Pattern)
- MVC uses the observer pattern to keep each view in sync with the model . Therefore whenever data
with in the model changes, each subscribing view (whether it‟s a webpage, a windows form or a form in
PDA) gets notified .
Composite (Structural Pattern)
- Each view uses composite pattern to make up its internal structure of visual elements (buttons, text
boxes, scrollbars etc.).
Strategy (Behavioral Pattern)
- The strategy design pattern defines the relationship between the view and controller . Hence multiple
controller can be used with a single view, depending upon the current state of the application. It allows
you to interchange the controller of a view when needed at design time and at runtime.
Factory (Creational Pattern)
- You can choose the default controller of a view when its rendered .