object oriented apologetics

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: vance@vancelucas.com• GitHub: http://github.com/vlucas

• Photo Set: http://www.flickr.com/photos/30728345@N05/galleries/72157622318592067/

Vance Lucas