Advanced PHP: Design Patterns - Dennis-Jan Broerse

10,310 views

Published on

Published in: Technology
5 Comments
30 Likes
Statistics
Notes
No Downloads
Views
Total views
10,310
On SlideShare
0
From Embeds
0
Number of Embeds
161
Actions
Shares
0
Downloads
583
Comments
5
Likes
30
Embeds 0
No embeds

No notes for slide

Advanced PHP: Design Patterns - Dennis-Jan Broerse

  1. 1. Advanced PHP A touch of Design Patterns Dennis-Jan Broerse - 13 juni 2008 Advanced PHP
  2. 2. Sources • Download the sources: http://www.ibuildings.nl/downloads/training username: dpc_2008 password: dpc_2008 Advanced PHP
  3. 3. Introduction • First conference where I’m a speaker Advanced PHP
  4. 4. Topics • Introduction to Design Patterns • Duck simulator • Weather application • Coffee bar • Traveller Advanced PHP
  5. 5. Introduction to Design Patterns • Best-practise ‘design’ solution • Lessons learned by other developers • Based on the OO principles • Language in-depended • Puzzles for the creative mind of developer Advanced PHP
  6. 6. Introduction to Design Patterns Advanced PHP
  7. 7. Introduction to Design Patterns OO Basics * Abstraction * Encapsulation * Polymorphism * Inheritance Advanced PHP
  8. 8. Introduction to Design Patterns OO Basics OO Principles * Abstraction * Encapsulate what varies * Encapsulation * Favour composition * Polymorphism over inheritance * Inheritance * Program to interfaces, not implementations Advanced PHP
  9. 9. Introduction to Design Patterns • It’s all about creating flexible designs that are maintainable and are able to deal with changes! • Don’t re-invent the wheel! • Load the design patterns into your brain and then design/build your application Advanced PHP
  10. 10. Duck simulator Advanced PHP
  11. 11. Duck simulator What we want • Creating as many ducks as needed • Ducks quack and swim Advanced PHP
  12. 12. Duck simulator What we want • That’s easy!! • We can use INHERITANCE • Yes, we know our OO basics Advanced PHP
  13. 13. Duck simulator What we want Advanced PHP
  14. 14. Duck simulator What we want Advanced PHP
  15. 15. Duck simulator First change • Our ducks have to fly! • No problem Advanced PHP
  16. 16. Duck simulator First change • Our ducks have to fly! • No problem Advanced PHP
  17. 17. Duck simulator First problem • Rubber ducks don’t fly! (and I don’t mean throwing) Advanced PHP
  18. 18. Duck simulator First change • This can't be the solution (imagine what you have to do if you want to create a decoy duck) Advanced PHP
  19. 19. Duck simulator First change • This can't be the solution (imagine what you have to do if you want to create a decoy duck) Advanced PHP
  20. 20. Duck simulator Cleaner solution • How about an interface? • Only implementing the interface if the duck is flyable • Hmm that’s it, that’s the solution Advanced PHP
  21. 21. Duck simulator Cleaner solution Advanced PHP
  22. 22. Duck simulator Cleaner solution Advanced PHP
  23. 23. Duck simulator Think again • What happens if we have to change the fly behaviour? • Exactly, we have to change all instances! • And we duplicate code • Wouldn’t it be dreamy if we can change its behaviour at runtime? Advanced PHP
  24. 24. Duck simulator Think again • Do you remember the OO basics and principles? • ‘Identify the aspects of your application that vary and separate them from what stays the same’ Advanced PHP
  25. 25. Duck simulator Last change Advanced PHP
  26. 26. Duck simulator Last change Advanced PHP
  27. 27. Duck simulator Benefits • Flexible • Maintainable • Extendable • No code duplication • Encapsulated • Change behaviour at runtime Advanced PHP
  28. 28. Duck simulator Code sample • Code sample Advanced PHP
  29. 29. Duck simulator Strategy Design Pattern • ‘The strategy pattern defines a family of algorithms, encapsulates each one, and makes them interchangeable. Strategy lets the algorithm vary independently from clients that use it.’ • Do you remember the OO basics and principles? Advanced PHP
  30. 30. Duck simulator Guru • Now you’ll understand why you should know about design patterns! Advanced PHP
  31. 31. Weather application Advanced PHP
  32. 32. Weather application What we want Advanced PHP
  33. 33. Weather application What we want Displays Pulls data WheatherData object Advanced PHP
  34. 34. Weather application Requirements • There are 3 get methods for temperature, humidity and pressure • measurementsChanged method will be automatically called if the measurements are changed • We have to implement the 3 display elements and they must be updated when measurements change Advanced PHP
  35. 35. Weather application First implementation Advanced PHP
  36. 36. Weather application First implementation Advanced PHP
  37. 37. Weather application First implementation Advanced PHP
  38. 38. Weather application What’s wrong • What if we want to add a new display? • Exactly: we have to change the code Advanced PHP
  39. 39. Weather application What’s wrong • Remember the OO basics and principles! • Not flexible • Not extendable • No encapsulation Advanced PHP
  40. 40. Weather application Let’s look • Investigate what’s going on • What is the relationship between the weather object and the display elements? • Maybe we can apply a design pattern? Advanced PHP
  41. 41. Weather application Let’s look • The relationship looks like a newspaper subscription • If you want to receive the newspaper, you have to subscribe yourself at the publisher • The publisher will send you your newspaper every time until you unsubscribe Advanced PHP
  42. 42. Weather application So.... • The weather object is the publisher • The display elements are the people who are willing to receive the newspaper Advanced PHP
  43. 43. Weather application And that is... • Yes, that is a design pattern! • Called ‘The Observer Pattern’ • Publisher == Weather object == Subject • People == Display elements == Observers • Subject notifies every observer to update Advanced PHP
  44. 44. Weather application Formal description • ‘The Observer Pattern defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.’ Advanced PHP
  45. 45. Weather application The class diagram Advanced PHP
  46. 46. Weather application The class diagram Advanced PHP
  47. 47. Weather application New design principle • Creating new observers won’t require a change in the subject • Changes to either the subject or an observer will not affect the other • Reusing a subject or an observer can independently of each other Advanced PHP
  48. 48. Weather application New design principle Advanced PHP 38
  49. 49. Weather application New design principle OO Principles * Encapsulate what varies * Favour composition over inheritance * Program to interfaces, not implementations * Strive for loosely coupled designs between objects that interact Advanced PHP 38
  50. 50. Weather application New design Advanced PHP
  51. 51. Weather application New design Advanced PHP
  52. 52. Weather application New design • Code sample Advanced PHP
  53. 53. Coffee bar Advanced PHP
  54. 54. Coffee bar What we want • An application that calculates the price of different beverages • The flexibility to add new beverages Advanced PHP
  55. 55. Coffee bar Simple solution Advanced PHP
  56. 56. Coffee bar Simple solution Advanced PHP
  57. 57. Coffee bar Condiments?? • No problem! • We have an OO application; just inherit Advanced PHP
  58. 58. Coffee bar First attempt Advanced PHP
  59. 59. Coffee bar First attempt Advanced PHP
  60. 60. Coffee bar First attempt • Euhm, this isn’t maintainable, this is a class explosion!! • Try again!! Advanced PHP
  61. 61. Coffee bar OK, sorry • Well that’s better, wouldn’t you agree? Advanced PHP
  62. 62. Coffee bar OK, sorry • Well that’s better, wouldn’t you agree? Advanced PHP
  63. 63. Coffee bar Really? • Did you really learn something? • Do you remember the OO basics and principles? Advanced PHP
  64. 64. Coffee bar New design principle Advanced PHP 49
  65. 65. Coffee bar New design principle OO Principles * Encapsulate what varies * Favour composition over inheritance * Program to interfaces, not implementations * Strive for loosely coupled designs between objects that interact * Classes should be open for extension, but closed for modification Advanced PHP 49
  66. 66. Coffee bar What we really want • We’d like to extend a beverage with condiments • We wouldn’t like to change the beverage • We’d like to add new beverages and condiments without changing the existing code Advanced PHP 50
  67. 67. Coffee bar New design pattern • The ‘Decorator Design Pattern’ saves our day • ‘The decorator pattern attaches additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.’ Advanced PHP 51
  68. 68. Coffee bar Our new design Advanced PHP 52
  69. 69. Coffee bar Our new design Advanced PHP 52
  70. 70. Coffee bar Our new design • This is really great! • Now we can say: One HouseBlend coffee with milk and mocha. What is the price? € 1,95 Advanced PHP 53
  71. 71. Coffee bar How does it work? • Wrap the houseBlend object with Milk object and wrap that with a mocha object • Ok, this is hard. Show me the code man. Advanced PHP 54
  72. 72. Coffee bar How does it work? • Code sample Advanced PHP 55
  73. 73. Traveller Advanced PHP
  74. 74. Traveller What we want • An application which tells us if the conditions are suitable enough to make the trip Advanced PHP
  75. 75. Traveller Wait a minute For example: • The traveller doesn’t want to make the trip if the average temperature of the destination is lower than his minimum required temperature Advanced PHP
  76. 76. Traveller First implementation • What do you think? Advanced PHP
  77. 77. Traveller First implementation • What do you think? Advanced PHP
  78. 78. Traveller First implementation • Indeed, not very smart! • Not possible to add requirements • Requirements changes, so trip class has to be changed Advanced PHP
  79. 79. Traveller Take that out Advanced PHP
  80. 80. Traveller Take that out Advanced PHP
  81. 81. Traveller That’s nice • We are able to create multiple specifications without changing other objects • Readable, maintainable, simple and effective • And it is a design pattern too!! ‘Hard-coded Specification Pattern’ Advanced PHP
  82. 82. Traveller But... • The specification knows too much • Not able to make logical specifications • Does violate some OO principles You know them by now, right? Advanced PHP
  83. 83. Traveller What we really want • A design which is flexible enough to validate almost every object • Validating against several conditions • Making logical expressions Advanced PHP
  84. 84. Traveller Let’s redesign Advanced PHP
  85. 85. Traveller Let’s redesign Advanced PHP
  86. 86. Traveller Wow, that’s heavy • Code sample Advanced PHP
  87. 87. Traveller This is ... • ‘The Specification Pattern’ by Martin Fowler (www.martinfowler.com) • Flexible, maintainable • Ready for complex validation • Loosely coupled • Most unknown design pattern Advanced PHP
  88. 88. Summary • Best-practise ‘design’ solution • Lessons learned by other developers • Based on the OO principles • Language in-depended • Puzzles for the creative mind of developer Advanced PHP
  89. 89. Summary Advanced PHP
  90. 90. Summary OO Basics * Abstraction * Encapsulation * Polymorphism * Inheritance Advanced PHP
  91. 91. Summary OO Principles OO Basics * Encapsulate what varies * Abstraction * Favour composition over inheritance * Encapsulation * Program to interfaces, not implementations * Polymorphism * Strive for loosely coupled designs between objects that interact * Inheritance * Classes should be open for extension, but closed for modification Advanced PHP
  92. 92. Summary • Strategy Design Pattern • Observer Design Pattern • Decorator Design Pattern • Specification Design Pattern Advanced PHP
  93. 93. Questions Advanced PHP
  94. 94. References • dennisjan@ibuildings.nl • www.ibuildings.nl / www.ibuildings.com • php|architect’s Guide to PHP Design Patterns • O’Reilly Head First Design Patterns • www.ibuildings.com/training/ Advanced PHP

×