Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Object Oriented Apologetics


Published on

In defense of object-oriented programming - How and why you should use object oriented programming for your next project. This talk is for PHP programmers who are just learning about object oriented code, who cling to old excuses ("object oriented code is slower"), or who are otherwise unconvinced of its usefulness. Concrete real-world examples of common scenarios and challenges that programmers face will be presented, and how taking an object oriented approach is better than a procedural one in most cases. Copious code examples in both object oriented and procedural approaches will be provided throughout, and the differences and benefits of the object oriented approach will be explained.

Published in: Technology, Education
  • Be the first to comment

Object Oriented Apologetics

  1. 1. Object Oriented Apologetics<br />Vance Lucas<br />CodeWorks 2009 Dallas<br />September 27, 2009<br />
  2. 2. What?<br />2<br />Not an apology<br />Greek root<br />- apologia (απολογία)<br />- “speaking in defense”<br />To defend the use of, and<br />provide rational reasoning for<br />
  3. 3. 3<br />Who is it for?<br />For People Who:<br />Are “on the fence” about OOP vs procedural<br />Are unconvinced of the usefulness of OOP<br />Want to learn WHY they should learn about OOP<br />
  4. 4. 4<br />Purpose: To Get You Hooked on OOP<br />
  5. 5. 5<br />NO Academic or Mundane Examples<br />
  6. 6. 6<br />No Shapes, Cars, Fruit, or Bicycles<br />
  7. 7. &lt;?phpclass myClass {     public function myClass(){     }     public function echoMe(){         echo &apos;me&apos;;     } } $mine=new myClass(); $mine-&gt;echoMe();<br />?&gt;<br />7<br />No “Hello World” Scripts<br />
  8. 8. So… Why OOP?<br />
  9. 9. Polymorphism<br />I nheritance<br />E ncapsulation<br />9<br />
  10. 10. 10<br />Polymorphism<br />
  11. 11. Making things that are not the same look the same<br />Relies on a defined interface<br />Inheritance is probably the most used method<br />The ability of type A to be used like type B<br />Think: Interchangeable types or components<br />11<br />Polymorphism<br />
  12. 12. 12<br />Real World: Different Implementations<br />
  13. 13. 13<br />Procedural - Inline<br />
  14. 14. 14<br />Object-oriented – Polymorphic Interface<br />
  15. 15. 15<br />Inheritance<br />
  16. 16. Extend from a parent class<br />“is-a” relationship<br />Creates hierarchal relationship<br />Get functionality for free<br />Global changes are easier<br />Inherits all functions and properties from parent<br />Think: A is a B, with a few differences<br />16<br />Inheritance<br />
  17. 17. 17<br />Controller: Zend Framework<br />
  18. 18. 18<br />Model: phpDataMapper<br />
  19. 19. 19<br />Warning: Keep Hierarchy Shallow<br />
  20. 20. 20<br />Encapsulation<br />
  21. 21. Hide specific implementation details<br />Reveal only methods and properties required to interact with the object<br />Limits interdependencies between components<br />Think: Separation of responsibilities<br />21<br />Encapsulation<br />
  22. 22. 22<br />Payment Interface – Exposed Methods<br />
  23. 23. 23<br />Planetoids (by Micah Jones)<br />
  24. 24. <ul><li>Asteroids responsible for their own movement
  25. 25. Different: velocities, sizes, shapes, rotations, color, and fragment pieces
  26. 26. All the code and math calculations for movement are encapsulated behind ‘move()’
  27. 27. Allows different types of objects and asteroids to be treated the same in code – “polymorphically”</li></ul>24<br />Planetoids: Code Abstraction<br />
  28. 28. Other OOP-Only Features?<br />25<br />
  29. 29. Lazy-Loading<br />
  30. 30. Uses __get() “magic” method in PHP5 object model<br />Also uses SPL interfaces to fire query on:<br />count()<br />foreach()<br />Used as a hook to retrieve related rows on call<br />Caches results so only 1 query is fired<br />Can eliminate N+1 query problem by mapping<br />27<br />Lazy-Loading: OOP Only<br />
  31. 31. Classes are actually custom types<br />Can type-hint for classes or interfaces<br />PHP Standard types:<br />string, int, float, boolean, array, object, null<br />resource<br />28<br />Custom Type Creation & Type-Hinting<br />
  32. 32. Other Reasons TO Use OOP?<br />
  33. 33. Easily group related properties/data<br />Avoid using globals or passing/returning arrays<br />Suppress errors ala ‘undefined index’<br />More?<br />Convenience (a.k.a. Laziness)<br />30<br />
  34. 34. Request object: Why not $_POST?<br />Data comes from multiple sources<br />POST/GET, XML, JSON, etc.<br />Other functions<br />isAjax(), isPost(), etc.<br />Sanitizing user input<br />Session object: Why not $_SESSION?<br />More options for saving/storing<br />Database, separate server, memcached, etc.<br />31<br />Request / Session Objects<br />
  35. 35. 32<br />Request Object: Convenience, too!<br />
  36. 36. Need an Example?<br />
  37. 37. E-commerce Cart: Work Scope<br /><ul><li>Basic categories (1-level)
  38. 38. Simple products, no options, stock, etc.
  39. 39. Simple checkout, no user accounts
  40. 40. integration
  41. 41. UPS rate quotes
  42. 42. Admin backend
  43. 43. Order fulfillment
  44. 44. Invoice/packing slip printing</li></li></ul><li>35<br />Simple Cart<br />
  45. 45. Simple Checkout<br />36<br />
  46. 46. 37<br />Simple UPS Integration<br />
  47. 47. So far it’s OK<br />It works<br />We finished and worked quickly<br />38<br />Status Check<br />
  48. 48. 39<br />Client Message<br />I talked to my next door neighbor’s cousin’s brother’s niece yesterday, and he says all the serious online stores have regular sales. That’s something I can do too, right?<br />- Bob<br />
  49. 49. 40<br />Product Sales<br />
  50. 50. 41<br />New Code for Product Sale<br />
  51. 51. We also have to add this code to the admin backend for customer invoices.<br />And to the email reciepts<br />Sin of code duplication<br />Code smell<br />42<br />Thoughts<br />
  52. 52. 43<br />Client Message<br />Hey,I was at the grocery store yesterday and my daughter got 2 candy bars for $1, when they were originally $0.75 each.<br />I know that if I am able to do this, I’ll get a lot of sales and it will make me rich. I need to be able to do this.<br />- Bob<br />
  53. 53. 44<br />Multi-Quantity Discounts<br />
  54. 54. New Code, Again<br />45<br />
  55. 55. We also have to add this code to the admin backend and other places again.<br />Sin of code duplication<br />We could use procedural functions for this<br />Where would we put them?<br />What responsibilities do they have?<br />46<br />Thoughts<br />
  56. 56. 47<br />What about the future?<br />
  57. 57. 48<br />Employee Discounts<br />
  58. 58. 49<br />Switching to FedEx<br />
  59. 59. Stock Checking<br />50<br />
  60. 60. Clearly, as the project grows, it will become a<br />maintenance nightmare if we continue on the<br />current path.<br />We don’t want our code to be the running joke of<br />the PHP community.<br />51<br />We need something better<br />
  61. 61. 52<br />
  62. 62. 53<br />Use the right tool for the right job<br />
  63. 63. 54<br />OOP: Right tool for this job<br />
  64. 64. Create a Cart class to store items<br />Encapsulate the pricing logic in an Item class<br />Single place to change the code<br />Item is responsible for knowing it’s price (?)<br />What does this imply?<br />55<br />Thoughts<br />
  65. 65. 56<br />Possible Code Changes<br />
  66. 66. Still storing cart in session, but now we can change it later when we need to scale<br />Cart gets item price so it can check quantities<br />Cart is responsible for knowing other items in cart<br />Better separation of responsibility<br />It’s not the job of the display logic to calculate the item’s price or apply discounts<br />What about changing to FedEx?<br />57<br />Thoughts<br />
  67. 67. 58<br />Re-factor it into two classes<br />
  68. 68. Package is responsible for knowing it’s own dimensions and weight<br />Quote is responsible for fetching a live rate quote from a carrier API service<br />Always think in terms of responsibility<br />What code is responsible for what functions?<br />Where does it go in my app?<br />Is this code doing too much?<br />59<br />Thoughts<br />
  69. 69. 60<br />Think about how an assembly line works<br />
  70. 70. OOP Myths and Misconceptions<br />
  71. 71. 62<br />Myth #1:<br />OOP is about code re-use<br />
  72. 72. 63<br />Truth:<br />Re-useable code is a by-product of good OO<br />
  73. 73. 64<br />Problem:<br />There are lots of ways to make re-useable code that are not object-oriented nor good.<br />It’s a bad goal.<br />
  74. 74. &lt;Code with functions and includes – re-useable&gt;<br />65<br />Functions are re-useable<br />
  75. 75. 66<br />Specific implementations are re-useable<br />
  76. 76. &lt;UPS-Specific API Code&gt;<br />or<br />&lt;Payment Gateway-specific API Code&gt;<br />67<br />Soft interfaces are re-useable<br />
  77. 77. You must set goals that will help direct you to your desired outcome<br />Goals narrow attention and direct efforts to goal-relevant activities, and away from perceived undesirable and goal-irrelevant actions<br />Re-use as a goal does not help you write good OO code. Re-use is a by-product of good OO.<br />68<br />Point: Set Good Goals<br />
  78. 78. 69<br />Myth #2:<br />Objects should always be modeled after real-world objects when possible<br />
  79. 79. 70<br />Truth:<br />Objects should be modeled and built based on what you need to complete your task<br />
  80. 80. 71<br />Problem:<br />Real-world object models are almost never useful in code<br />
  81. 81. 72<br />Real-World Objects Change<br />
  82. 82. 73<br />You are modeling things that don’t exist<br />
  83. 83. 74<br />
  84. 84. 75<br />Myth #3:<br />Everything should be objects<br />
  85. 85. 76<br />Truth:<br />Make objects for only what you need to. Most of the time this is data. Don’t over-complicate your code when it’s not necessary.<br />
  86. 86. 77<br />Problem:<br />Not everything your code does can be easily represented with an object<br />
  87. 87. 78<br />Application Flow<br />MVC diagram for<br />XEROX PARC 1978-79<br />
  88. 88. 79<br />
  89. 89. Programming PHP for over 10 years<br />Web:<br />Twitter: @vlucas<br />Email:<br />GitHub:<br />Photo Set:<br />80<br />Vance Lucas<br />