Object Oriented Apologetics
Vance LucasCodeWorks 2009 Dallas
September 27, 2009
2
What?
Not an apologyGreek root- apologia (απολογία)- “speaking in defense”
To defend the use of, andprovide rational reasoning for
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
Purpose: To Get You Hooked on OOP
5
NO Academic or Mundane Examples
6
No Shapes, Cars, Fruit, or Bicycles
7
<?php class myClass { public function myClass(){ } public function echoMe(){ echo 'me'; } } $mine=new myClass(); $mine->echoMe();
?>
No “Hello World” Scripts
SO… WHY OOP?
9
Polymorphism
I nheritance
E ncapsulation
10
Polymorphism
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
Polymorphism
12
Real World: Different Implementations
13
Procedural - Inline
14
Object-oriented – Polymorphic Interface
15
Inheritance
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
Inheritance
17
Controller: Zend Framework
18
Model: phpDataMapper
19
Warning: Keep Hierarchy Shallow
20
Encapsulation
21
• Hide specific implementation details• Reveal only methods and properties required to
interact with the object
• Limits interdependencies between components• Think: Separation of responsibilities
Encapsulation
22
Payment Interface – Exposed Methods
23
Planetoids (by Micah Jones)
24
• Asteroids responsible for their own movement• Different: velocities, sizes, shapes, rotations, color,
and fragment pieces• All the code and math calculations for movement are
encapsulated behind ‘move()’• Allows different types of objects and asteroids to be
treated the same in code – “polymorphically”
Planetoids: Code Abstraction
OTHER OOP-ONLY FEATURES?
25
Lazy-Loading
27
• Uses __get() “magic” method in PHP5 object model
• Also uses SPL interfaces to fire query on:– count()– foreach()
• 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
28
• Classes are actually custom types• Can type-hint for classes or interfaces
• PHP Standard types:– string, int, float, boolean, array, object, null– resource
Custom Type Creation & Type-Hinting
OTHER REASONS TO USE OOP?
• Easily group related properties/data• Avoid using globals or passing/returning arrays• Suppress errors ala ‘undefined index’• More?
Convenience (a.k.a. Laziness)
30
31
• 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
32
Request Object: Convenience, too!
NEED AN EXAMPLE?
E-commerce Cart: Work Scope• Basic categories (1-level)• Simple products, no options, stock, etc.• Simple checkout, no user accounts• Authorize.net integration• UPS rate quotes• Admin backend• Order fulfillment• Invoice/packing slip printing
35
Simple Cart
36
Simple Checkout
37
Simple UPS Integration
38
• So far it’s OK• It works• We finished and worked quickly
Status Check
39
Client MessageI 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
40
Product Sales
41
New Code for Product Sale
42
• 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
Thoughts
43
Client MessageHey, 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
44
Multi-Quantity Discounts
45
New Code, Again
46
• 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?
Thoughts
47
What about the future?
48
Employee Discounts
49
Switching to FedEx
Stock Checking
50
51
Clearly, as the project grows, it will become amaintenance nightmare if we continue on thecurrent path.
We don’t want our code to be the running joke ofthe PHP community.
We need something better
52
53
Use the right tool for the right job
54
OOP: Right tool for this job
55
• 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?
Thoughts
56
Possible Code Changes
57
• 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 items in cart
• 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?
Thoughts
58
Re-factor it into two classes
59
• 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?
Thoughts
60
Think about how an assembly line works
OOP MYTHS AND MISCONCEPTIONS
62
Myth #1:OOP is about code re-use
63
Truth:Re-useable code is a by-product of good OO
64
Problem:There are lots of ways to make re-useable code
that are not object-oriented nor good.It’s a bad goal.
65
<Code with functions and includes – re-useable>Functions are re-useable
66
Specific implementations are re-useable
67
<UPS-Specific API Code>or<Payment Gateway-specific API Code>
Soft interfaces are re-useable
68
• 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
69
Myth #2:Objects should always be modeled after real-world
objects when possible
70
Truth:Objects should be modeled and built based on
what you need to complete your task
71
Problem:Real-world object models are almost never useful
in code
72
Real-World Objects Change
73
You are modeling things that don’t
exist
74
75
Myth #3:Everything should be objects
76
Truth: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.
77
Problem:Not everything your code does can be easily
represented with an object
78
Application Flow
MVC diagram forXEROX PARC 1978-79
79
80
• Programming PHP for over 10 years• Web: http://www.vancelucas.com• Twitter: @vlucas• Email: [email protected]• GitHub: http://github.com/vlucas
• Photo Set: http://www.flickr.com/photos/30728345@N05/galleries/72157622318592067/
Vance Lucas