Let us understand design pattern
57 likes36,283 views
This session covers details on What is a design pattern, Why Design pattern, When to use design pattern, Types of Design Pattern....etc.
![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.](https://image.slidesharecdn.com/letusunderstanddesignpattern-130724011212-phpapp01/85/Let-us-understand-design-pattern-28-320.jpg)
Ad
More Related Content
What's hot (20)
Similar to Let us understand design pattern (20)
Ad
More from Mindfire Solutions (20)
Ad
Recently uploaded (20)
Let us understand design pattern
- 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 ?
- 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 .
Editor's Notes
- #8: Source from - http://www.codeproject.com/Articles/98598/How-I-explained-Design-Patterns-to-my-wife-Part-1