DESIGN PATTERNS -- Mudabbir Warsi
AGENDA <ul><li>Introduction </li></ul><ul><li>Myths About Design Patterns </li></ul><ul><li>Design Principles </li></ul><u...
Introduction <ul><li>What is a “Pattern” ? </li></ul>“ Each Pattern describes a problem which occurs over and over again i...
Myths about Design Patterns <ul><li>Seen one, seen them all </li></ul><ul><li>Patterns are for (Object Oriented) design or...
Design Principles <ul><li>L iskov  S ubstitution  P rinciple </li></ul><ul><li>S ingle  R esponsibility  P rinciple </li><...
Design Principles Contd… <ul><li>DRY P rinciple </li></ul><ul><li>I nterface  S egregation  P rinciple </li></ul>“ Solve t...
Basic Elements of a Design Pattern <ul><li>Problem </li></ul><ul><li>Solution </li></ul><ul><li>Consequences </li></ul><ul...
Categories of Design Patterns <ul><li>Creational </li></ul>Abstract Factory Factory Method Singleton Prototype Builder Str...
The Pattern Life Cycle Real World  Projects Pattern Mining Author Version Preliminary Document -ation Pattern Polishing Re...
Pattern Hatching 4. A Miracle Occurs 7. Test the Solution 6. Instantiate the Pattern 5. Evaluate Solution 1. Familiarize y...
Pattern Refactoring <ul><li>“  Refactoring  is the process of changing a software system in such a way that it does not al...
Example Design Patterns <ul><li>INTENT  </li></ul><ul><li>Ensure a class has only one Instance and provide a global point ...
Singleton Contd… <ul><li>IMPLEMENTATION </li></ul><ul><li>class Singleton { </li></ul><ul><li>public: </li></ul><ul><li>st...
Singleton Contd… <ul><ul><ul><ul><li>The “leaking” Singleton </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Thread - Safe Si...
Inside Model-View-Controller 1. The User did something 2. Change your state 3. Change your display 4. I have changed 5. I ...
A Closer Look 1. The User did something 2. Change your state 3. Change your display 4. I have changed 5. I need your state...
Observer I’d like to register as an observer My State  has changed Observable Observers All these Observers will be notifi...
Strategy The user did something We can swap in another behavior for the View by changing the Controller The Controller is ...
Composite Paint ( ) The View is a Composite of GUI components ( buttons, labels, text boxes etc). The top level component ...
MVC in Action <ul><li>MVC and the Web </li></ul>Servlet / Controller JSP / View MODEL / DB / Business Logic Bean 1. HTTP R...
EXPERT COMMENTS Today there are more patterns than in the GOF book: Learn them as well. Go for simplicity and don’t become...
Q & A
Upcoming SlideShare
Loading in...5
×

Design patterns

1,961

Published on

Introduction on Design patterns followed by a detailed explanation of Singleton design pattern and composite pattern (MVC).

Published in: Education, Technology, Design
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,961
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Design patterns

  1. 1. DESIGN PATTERNS -- Mudabbir Warsi
  2. 2. AGENDA <ul><li>Introduction </li></ul><ul><li>Myths About Design Patterns </li></ul><ul><li>Design Principles </li></ul><ul><li>Elements of a Design Pattern </li></ul><ul><li>Categories of Design Patterns </li></ul><ul><li>Pattern Hatching </li></ul><ul><li>Pattern Refactoring </li></ul><ul><li>Example Design Patterns </li></ul><ul><li>Inside Model View Controller </li></ul><ul><li>Q & A </li></ul>
  3. 3. Introduction <ul><li>What is a “Pattern” ? </li></ul>“ 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, with out ever doing it the same way twice” -- Christopher Alexander: The Timeless way of Building <ul><li>Why Design Patterns ? </li></ul><ul><ul><li>Patterns enable us to reuse solutions , establish common terminology </li></ul></ul><ul><ul><li>Patterns enable us to achieve software which is: </li></ul></ul><ul><ul><ul><ul><li>Extensible </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Maintainable </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Readable </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Reusable </li></ul></ul></ul></ul><ul><li>Where do we use Design Patterns ? </li></ul><ul><ul><li>Application Software </li></ul></ul><ul><ul><li>Libraries </li></ul></ul><ul><ul><li>Frameworks </li></ul></ul>
  4. 4. Myths about Design Patterns <ul><li>Seen one, seen them all </li></ul><ul><li>Patterns are for (Object Oriented) design or implementation </li></ul><ul><li>Patterns guarantee reusable software, high productivity ,world peace, .. </li></ul><ul><li>The Pattern community is self-serving, even conspirational </li></ul><ul><li>A Pattern is a solution to a problem in context </li></ul>
  5. 5. Design Principles <ul><li>L iskov S ubstitution P rinciple </li></ul><ul><li>S ingle R esponsibility P rinciple </li></ul>“ A module should be open for extension but closed for modification.” <ul><li>S table D ependencies P rinciple </li></ul><ul><li>O pen C losed P rinciple </li></ul>“ Sub-classes should be substitutable for their base class .” “ There should never be more than one reason for a class to change .” <ul><li>L east K nowledge P rinciple ( L aw of D emeter) </li></ul>“ Talk only to your immediate friends .” “ Depend in the direction of stability .”
  6. 6. Design Principles Contd… <ul><li>DRY P rinciple </li></ul><ul><li>I nterface S egregation P rinciple </li></ul>“ Solve the most important problem in the simplest possible way.” <ul><li>D ependency I nversion P rinciple </li></ul><ul><li>KISS P rinciple </li></ul>“ Every piece of knowledge must have a single, unambiguous and authoritative representation with in the system .” “ Many client specific interfaces are better than one general purpose interface .” <ul><li>C ommon R euse P rinciple </li></ul>“ Classes that aren’t used together, should not be grouped together .” “ Depend upon Abstractions. Never depend upon Concretions .”
  7. 7. Basic Elements of a Design Pattern <ul><li>Problem </li></ul><ul><li>Solution </li></ul><ul><li>Consequences </li></ul><ul><li>Name </li></ul>
  8. 8. Categories of Design Patterns <ul><li>Creational </li></ul>Abstract Factory Factory Method Singleton Prototype Builder Structural Adapter Decorator Flyweight Composite Bridge Facade Proxy Behavioral Mediator Iterator Visitor Observer Chain of Responsibility Strategy State Momento Command Interpreter Template Method Let you compose objects and classes into larger structures Involve object Instantiation and all provide a way to decouple a client from the object it needs to create Concerned with how objects and classes interact and distribute responsibility
  9. 9. The Pattern Life Cycle Real World Projects Pattern Mining Author Version Preliminary Document -ation Pattern Polishing Reusable Version Pattern Reuse Incident Occurs of a pattern Discover Patterns Document Document Analyse / Rule of Three Feedback Modification PHASE 1: MINING Author World PHASE 2: POLISHING Pattern Community World PHASE 3: REUSE Pattern User World
  10. 10. Pattern Hatching 4. A Miracle Occurs 7. Test the Solution 6. Instantiate the Pattern 5. Evaluate Solution 1. Familiarize yourself with Patterns 2. Characterize nature of u r problem 3. Apply Matching
  11. 11. Pattern Refactoring <ul><li>“ Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure. It is a disciplined way to clean up code that minimizes the chances of introducing bugs.” </li></ul><ul><li>Martin Fowler, Refactoring: Improving the design of existing code </li></ul><ul><li>Principles of Refactoring </li></ul><ul><ul><li>First Refactoring Step </li></ul></ul><ul><ul><li>Refactor in Small Steps </li></ul></ul><ul><ul><li>Test every Refactoring </li></ul></ul><ul><ul><li>Back track if Refactoring fails </li></ul></ul><ul><li>“ Refactoring to Patterns not only improves a code’s structure but adds a time tested solution to a common design problem to the code.” </li></ul><ul><li>Joshua Kerievsky, Refactoring to Patterns </li></ul><ul><li>Refactoring Directions </li></ul><ul><ul><li>Taking code to a Design Pattern </li></ul></ul><ul><ul><li>Taking code towards a Design Pattern </li></ul></ul><ul><ul><li>Taking code away from a Design Pattern </li></ul></ul>
  12. 12. Example Design Patterns <ul><li>INTENT </li></ul><ul><li>Ensure a class has only one Instance and provide a global point of access to it. </li></ul><ul><li>MOTIVATION </li></ul><ul><li>For some classes multiple instances do not make sense or may lead to </li></ul><ul><li>security risk (Eg: Thread Pools, Security Manager, System Clock etc) </li></ul><ul><li>STRUCTURE </li></ul>Singleton static getInstance( ) // Other useful Methods static uniqueInstance // Other useful data return uniqueInstance <ul><li>NAME </li></ul><ul><li>Singleton </li></ul>
  13. 13. Singleton Contd… <ul><li>IMPLEMENTATION </li></ul><ul><li>class Singleton { </li></ul><ul><li>public: </li></ul><ul><li>static Singleton* getInstance( ) { // Unique point of access </li></ul><ul><li>if ( !uniqueInstance) </li></ul><ul><li>uniqueInstance = new Singleton; </li></ul><ul><li>return uniqueInstance; </li></ul><ul><li>} </li></ul><ul><li>private: </li></ul><ul><li>Singleton ( ); // Prevent from creating a new Instance </li></ul><ul><li>Singleton (const Singleton& ); // Prevents from creating another copy </li></ul><ul><li>Singleton& operator= (const Singleton& ); // Prevents self-assignament </li></ul><ul><li>~ Singleton ( ); // Prevents accidental delete of singleton object </li></ul><ul><li>static Singleton* uniqueInstance; // The one and the only instance </li></ul><ul><li>}; </li></ul>
  14. 14. Singleton Contd… <ul><ul><ul><ul><li>The “leaking” Singleton </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Thread - Safe Singletons </li></ul></ul></ul></ul><ul><li>Different Variation of Singleton </li></ul><ul><ul><ul><ul><li>The Meyers Singleton </li></ul></ul></ul></ul><ul><ul><ul><ul><li>The Phoenix Singleton </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Singletons with Longevity </li></ul></ul></ul></ul>
  15. 15. Inside Model-View-Controller 1. The User did something 2. Change your state 3. Change your display 4. I have changed 5. I need your state information VIEW Gives you a presentation of the model. It gets the state and data to be displayed from the model CONTROLLER Takes user input and figures out what it means to the model MODEL The model holds all the data, state and application logic. It provides an interface to manipulate and retrieve its state.
  16. 16. A Closer Look 1. The User did something 2. Change your state 3. Change your display 4. I have changed 5. I need your state information STRATEGY The view and controller implement the STRATEGY pattern: The view is an object that is configured with a strategy. The controller provides the strategy. Using the strategy pattern keeps the view decoupled from the model. OBSERVER The model implements the OBSERVER to keep interested objects updated when the state change occurs. Using the observer patterns keeps the model decoupled with the view n controller COMPOSITE The view implements the COMPOSITE pattern: The display consists of nested set of windows, panels, buttons, text boxes etc. When the controller tells the view to update, it only has to tell the top view component and the COMPOSITE takes care of the rest.
  17. 17. Observer I’d like to register as an observer My State has changed Observable Observers All these Observers will be notified whenever state changes in the Model Any object that’s interested in the state change of the Model registers with the Model as an Observer. INTENT: Define a one – many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
  18. 18. Strategy The user did something We can swap in another behavior for the View by changing the Controller The Controller is the Strategy for the View – it’s the object that knows how to handle the user action. The View delegates to the Controller to handle the user actions The View only worries about the presentation, the Controller worries about translating user inputs to actions on the Model INTENT: Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithms vary independently from the client that uses it.
  19. 19. Composite Paint ( ) The View is a Composite of GUI components ( buttons, labels, text boxes etc). The top level component contains other components, which contain other components and so on until you get to the leaf nodes. <ul><li>OTHER PATTERNS USED: </li></ul><ul><ul><ul><ul><li>Decorator </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Chain Of Responsibility </li></ul></ul></ul></ul>INTENT: Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
  20. 20. MVC in Action <ul><li>MVC and the Web </li></ul>Servlet / Controller JSP / View MODEL / DB / Business Logic Bean 1. HTTP Request 5. HTTP Response 2 3 4 <ul><li>Document View Architecture in MFC </li></ul><ul><li>SWING API in Java </li></ul><ul><li>Delegates in .NET </li></ul>
  21. 21. EXPERT COMMENTS Today there are more patterns than in the GOF book: Learn them as well. Go for simplicity and don’t become over-excited. If you can come up with a simpler solution without applying a pattern, then go for it. Shoot for practical extensibility. Don’t provide hypothetical generality; be extensible in ways that matter. Patterns are Tools not Rules- They need to be tweaked and adapted to your problem. John Vlissides Richard Helm Ralph Johnson Eric Gamma
  22. 22. Q & A

×