Slideshow Transcript

1. Slide 1: Design Patterns for 70% of genious programmers Aamir Khan Solution Architect
2. Slide 2: Design Patterns for 70% of programmers in the world Saurabh Verma Solution Architect I blog at http://www.domaindrivendesign.info
3. Slide 3: Agenda • Do you OOPs? • Design Patterns? Why • Design Patterns? What • Design Patterns? How • I hate my job
4. Slide 4: Normal Classes vs Abstract Classes vs Interfaces Normal Class: This is a normal class  Abstract Class: These cannot be instantiated directly. They may provide partial implementations and exists solely for the purpose of inheritance. Interfaces: Defines a contract. Concrete implementations needs to implement each property and method as per contract. Shut up ! We know all this
5. Slide 5: Million Dollar Question? What is Why?
6. Slide 6: Normal Class vs Abstract Class? If a particular class is a entity which is not required to be instantiated by the application directly, go for Abstract Class Employee can be abstract class
7. Slide 7: Abstract Class vs Interfaces? If a particular class contains any default behavior, go for Abstract Class If every concrete class has its own implementation, go for Interfaces Work – Management, Programming
8. Slide 8: MOVIES & ACTORS Salman Khan riding bike Shahrukh Khan Actors in a Movie
9. Slide 9: IS-A vs HAS-A vs CAN-DO IS-A Inheritance Shahrukh Khan is an ACTOR HAS-A Composition Movie has ACTORS CAN-DO Interfaces Salman Khan can DRIVE BIKE
10. Slide 10: What is a Pattern • An 'element of reusable software’ • A design pattern systematically names, motivates, and explains a general design that addresses a recurring design problem in object- oriented systems. • It describes the problem, the solution, when to apply the solution, and its consequences. • It also gives implementation hints and examples. The solution is a general arrangement of objects and classes that solve the problem. The solution is customized and implemented to solve the problem in a particular context.
11. Slide 11: History of Software Patterns
12. Slide 12: What Wikipedia says, • A design pattern is a general repeatable solution to a commonly occurring problem in software design. • A design pattern is not a finished design that can be transformed directly into code. • Algorithms are not thought of as design patterns.
13. Slide 13: Let’s understand design patterns by purpose
14. Slide 14: Let’s understand the purpose Final Product Creational Patterns Behavioral Patterns Structural Patterns +
15. Slide 15: Let’s understand the purpose
16. Slide 16: Design Patterns as per their PURPOSE
17. Slide 17: Creational Patterns
18. Slide 18: Factory Method
19. Slide 19: Factory Method Define an interface for creating an object, but let subclass decide which class to instantiate • Prevents creation of any additional instances, while simultaneously allowing global access • Creation can be delayed until it is actually required
20. Slide 20: Factory Method System.Data.SqlClient.SqlClientFactory
21. Slide 21: Abstract Factory Pattern
22. Slide 22: Abstract Factory Pattern Provide an interface for creating families of related or dependent objects without specifying their concrete classes. • Provides creation of families of related or dependent objects without specifying their concrete class
23. Slide 23: Abstract Factory Method System.Data.Common.DbProviderFactories
24. Slide 24: Singleton Pattern
25. Slide 25: Singleton Pattern Ensure a class has only one instance, and provide a global point to it. • Prevents creation of any additional instances, while simultaneously allowing global access • Creation can be delayed until it is actually required
26. Slide 26: Singleton Pattern System.Data.SqlClient.SqlClientFactory
27. Slide 27: Structural Patterns
28. Slide 28: Façade Pattern
29. Slide 29: Façade Pattern Provide a unified interface to set of interfaces in a subsystem. • Is generally one side of the exterior of a building, especially the front • Origin from a FRENCH word means “face” or “front”
30. Slide 30: Façade Pattern Its all about the service
31. Slide 31: Decorator Pattern
32. Slide 32: Decorator Pattern Attach additional responsibilities to an object dynamically. • Flexible alternative to subclassing for extending functionality • Allows dynamic and transparent addition and removal of responsibilities without affecting object simple actress in role of modern girl in role of homely girl (act) (go out and act) (be in home and act)
33. Slide 33: Decorator Pattern System.IO.BufferedStream:Stream
34. Slide 34: Composite Pattern
35. Slide 35: Composite Pattern Compose objects into tree structures to represent part-whole hierarchies • When dealing with collections of objects, there are often operations that are appropriate for both a single object and the entire collection • Treats individual objects and composition of objects uniformly Example: b)Every object “IS-A” shape c)Every shape “HAS-A” draw behavior
36. Slide 36: Composite Pattern System.Web.UI.Control (Render Mechanism)
37. Slide 37: Composite Pattern
38. Slide 38: Adapter Pattern
39. Slide 39: Adapter Pattern Convert the interface of a class into another interface clients expect • Lets classes work together that couldn’t work otherwise • Works good for making compliance Legacy Application Component Adapter Framework
40. Slide 40: Adapter Pattern GearsTypelib.HtmlDialogHostClass (Interop.GearsTypelib)
41. Slide 41: Decorator vs Adapter Decorator looks like Adapter which “decorates” an existing class to make it compatible. Though, Decorator doesn’t wants you to decorate every method in the Adapted class. But who has stopped from doing it. “Never underestimate the power of a developer”
42. Slide 42: Decorator vs Façade Façade is a way of hiding a complex system inside a simpler interface, whereas Decorator adds function by wrapping a class.
43. Slide 43: Behavioural Patterns
44. Slide 44: Command Pattern
45. Slide 45: Command Pattern Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests. • If all commands can service a specific request, they can be entertained by the invoker • Concrete command performs the action on Receiver • Encapsulate method invocation One Receiver and Multiple actions
46. Slide 46: Command Pattern System.ComponentModel.Design.MenuCommand
47. Slide 47: Command Pattern Saurabh.Learning.DesignPatterns.Patterns.CommandPattern
48. Slide 48: Strategy Pattern
49. Slide 49: Strategy Pattern Define strategies for a performing a behavior and change them dynamically as per requirement • This lets the algorithm vary independently from clients that uses it • It is about choice, which affects outcomes
50. Slide 50: Strategy Pattern System.Collections.ArrayList
51. Slide 51: Template Method
52. Slide 52: Template Method Define the skeleton of an algorithm in an operations, deferring some steps to subclass • Main algorithm skeleton is defined in a base class and subclasses can then plug in their own details without affecting the algorithm itself • Uses Inheritance – Abstract Class defines the template (algorithm) and Concrete class manages the implementation. • Template uses the implementation on demand
53. Slide 53: Template Method
54. Slide 54: Strategy Pattern vs Template Method • Strategy allows callers to change the algorithm or order of steps whereas Template method allow steps to be modified • Strategy uses Interfaces whereas Template method uses Inheritance
55. Slide 55: I hate my job
56. Slide 56: Top 5 ADVICES NOT TO FOLLOW
57. Slide 57: Reflect when you want 
58. Slide 58: Answers, anybody?
59. Slide 59: CONTENT STOLEN FROM  BOOKS: Head First Design Patterns Design Patterns in C# Design Patterns WEBSITES: Wikipedia, MSDN, doFactory and GOOGLE
60. Slide 60: Learn it all, at my blog http://www.domaindrivendesign.info Don’t contact me at, saurabh.net [at] gmail.com Saurabh Verma Solution Architect