Your SlideShare is downloading. ×
  • Like
Object Oriented Apologetics
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Object Oriented Apologetics


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 …

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
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads


Total Views
On SlideShare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


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