Introduction To Design Patterns


Published on

An intro to Design patterns

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Introduction To Design Patterns

  1. 1. Introduction to Design Patterns Raju Golla …………………………………… .…….
  2. 2. What are Design Patterns <ul><li>General and reusable solutions to common problems in </li></ul><ul><li>software design. </li></ul><ul><li>Solutions to problems that have already been resolved </li></ul><ul><li>Structure or interfaces how the source code should be organised. </li></ul><ul><li>Interaction between Classes i.e., collaboration </li></ul><ul><li>.NET Framework BCL already makes extensive use of patterns. </li></ul><ul><li>Deal with higher level application and software design (Enterprise architecture) as well as low level abstractions on top of the source code. </li></ul><ul><li>It is a dialect for programmers, use templates rather than reinventing </li></ul><ul><li>the wheel, improves system and application design. </li></ul>
  3. 3. Activity
  4. 4. What they are not? <ul><li>Reusable components </li></ul><ul><li>such as assemblies, algorithms or class specifications </li></ul>
  5. 5. History <ul><li>Success architect Christopher Alexander </li></ul><ul><li>book 'A Pattern Language: Towns, builds, construction, </li></ul><ul><li>1977' (Non IT) </li></ul><ul><li>Design patterns: Elements of Reusable Object Oriented Software </li></ul><ul><li>Gang of Four: Erich Gamma, Richard Helm, Ralph Johnson </li></ul><ul><li>and John Vlissides (1995). </li></ul><ul><li>First time documented successful design patterns. </li></ul>
  6. 6. Classifications <ul><li>Design patterns for </li></ul><ul><li>Object oriented programming. </li></ul><ul><li>Functional programming. </li></ul><ul><li>Creational </li></ul><ul><li>Structural </li></ul><ul><li>Behavioral </li></ul><ul><li>Security </li></ul><ul><li>Concurrency </li></ul><ul><li>Sql </li></ul><ul><li>User interface </li></ul><ul><li>Relational </li></ul><ul><li>Social </li></ul><ul><li>Distributed </li></ul>
  7. 7. Singleton pattern <ul><li>Member of Creational family of patterns </li></ul><ul><li>The intention of this pattern is to ensure that a class has only one instance </li></ul><ul><li>Make the class itself is responsible for keeping track of its sole instance </li></ul><ul><li>The class must be accessible to clients </li></ul><ul><li>There can be only one </li></ul>
  8. 8. Singleton implementation classic
  9. 9. Thread safe
  10. 10. Outcome <ul><li>The default implementation of Singleton pattern is not thread-safe, it should not be used in multi threaded applications i.e., ASP.NET web apps. </li></ul><ul><li>Introduces tight coupling among collaborating classes. </li></ul><ul><li>Difficult to test </li></ul><ul><li>It is feasible to use IOC (Inversion of Control) to avoid tight coupling and testability issues. </li></ul>
  11. 11. Strategy <ul><li>Encapsulate related algorithms </li></ul><ul><li>Lets the algorithm vary and evolve from the class using it </li></ul><ul><li>Allows the class to maintain a separate purpose </li></ul><ul><li>Separates the implementation from the delivery of its results. </li></ul>
  12. 12. Strategy – when to be used? <ul><li>Switch statements. </li></ul><ul><li>Decouple algorithm implementation from a class. </li></ul><ul><li>Adding a new method (Calculation) requires class modification. </li></ul>
  13. 13. Strategy implementation <ul><li>Interface </li></ul><ul><li>Implementing classes </li></ul>
  14. 14. Implementation continued.. Client
  15. 15. Decorator <ul><li>Structural design pattern </li></ul><ul><li>Allows to add functionality to objects at run time. </li></ul><ul><li>Alternative to sub classing. </li></ul><ul><li>Design flexibility </li></ul><ul><li>Allows adding behaviour to objects at run time. </li></ul><ul><li>Supports open closed principle. </li></ul>
  16. 16. When to consider? <ul><li>Legacy systems </li></ul><ul><li>Add functionality to UI controls (Controls, buttons etc) </li></ul><ul><li>Sealed classes (it is feasible to add </li></ul>
  17. 17. Implementation <ul><li>Classic implementation </li></ul><ul><li>-Base class </li></ul><ul><li>Derived classes </li></ul>
  18. 18. Implementation continued… <ul><li>Client </li></ul>Output
  19. 19. Decorator class
  20. 20. Implementation continued… <ul><li>Concrete decorator </li></ul>
  21. 21. Implementation continued… <ul><li>Client </li></ul>Output
  22. 22. Implementation continued…
  23. 23. Continued… Client
  24. 24. State <ul><li>Member of behavioral pattern </li></ul><ul><li>Allows object to change methods behaviour based on state of the object, not the configuration. </li></ul><ul><li>Encapsulate the logic of each state into a single object </li></ul><ul><li>Allows for dynamic state discovery </li></ul><ul><li>Makes unit testing easier and efficient </li></ul>
  25. 25. Example <ul><li>Jira issue Object </li></ul>
  26. 26. State – class diagram
  27. 27. Benefits <ul><li>Separation of concerns </li></ul><ul><li>Transition between sates is explicit and clear. </li></ul><ul><li>Reuse of the state object. </li></ul><ul><li>Simplify the program </li></ul><ul><li>Easier maintainability. </li></ul>
  28. 28. References <ul><li>Microsoft Patterns and practices at </li></ul><ul><li> </li></ul><ul><li>Microsoft Patterns and practices team: Application architecture guide </li></ul><ul><li> </li></ul><ul><li>Head First design patterns </li></ul><ul><li>C# in depth </li></ul>