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
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
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
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
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
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
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
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.
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
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.
FACTORY PATTERN IN .NET -
IDbCommand.CreateParameter - Convert.ToBoolean - WebRequest: HttpWebRequest, FtpWebRequest - ASP.NET Runtime
FACTORY PATTERN – WHEN ?
Do we need to have derived classes figure out what to instantiate and decouple client from instantiated class ?
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.
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.
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
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
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.
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.
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.
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.
OBSERVER PATTERN – WHEN ?
Do various entities need to know about events that have occurred? How to keep dependent object up-to-date.
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.
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.
STRATEGY PATTERN IN .NET Membership
Providers Role Providers Site Map Providers Session State Providers Profile Providers Web Event Providers Web Parts Personalization Providers
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 .