The document discusses object-oriented programming and APIs. It contrasts the "classic view" of objects representing physical things with the "modern view" of objects representing collections of related behaviors. Well-designed APIs follow principles like single responsibility, open/closed design, and dependency inversion. Poorly designed APIs exhibit issues like global state, tight coupling, duplication, and premature optimization. The talk emphasizes that object-oriented patterns like polymorphism, encapsulation, and applying SOLID principles result in modular, reusable, and maintainable code, though at a higher initial cost.

1. Don’t Be STUPID
Grasp SOLID!
Anthony Ferrara
NorthEastPHP 2013

2. Let’s Talk
Object
Oriented
Programming

3. What
Is An
Object?

4. Classic View
Object == Physical “Thing”

5. Classic View
Object == Physical “Thing”
Methods == Actions on “Thing”

6. Classic View
Object == Physical “Thing”
Methods == Actions on “Thing”
Properties == Description of “Thing”

7. Animal
MammalBird Fish
CatCow Dog
Lion Feline Cheetah

8. Classic View
$lion = new Lion;
$lion->roar();
$lion->walkTo($point);
$lion->hunt($zebra);
$lion->sleep();

9. Is This Realistic?

10. Classic View
$lion = new Lion;
$lion->roar();
$lion->walkTo($point);
$lion->hunt($zebra);
$lion->sleep();

11. Classic View
$lion = new Lion;
$lion->roar();
$lion->walkTo($point);
$lion->hunt($zebra);
$lion->sleep();
Does A Lion Have
A Button To Make
It Roar?

12. Classic View
$lion = new Lion;
$lion->roar();
$lion->walkTo($point);
$lion->hunt($zebra);
$lion->sleep();
Does A Lion Have
A Button To Make
It Roar?What Does It
Mean For An
Object To “Hunt”?

13. Classic View
$lion = new Lion;
$lion->roar();
$lion->walkTo($point);
$lion->hunt($zebra);
$lion->sleep();
Does A Lion Have
A Button To Make
It Roar?What Does It
Mean For An
Object To “Hunt”?
What Is A Lion In
Relation To Our
Application?

14. The Classical
Model Is Easy To
Understand

16. The Classical
Model Is
Completely
Impractical

17. “Modern” View
Object == Collection Of (Related)
Behaviors

18. “Modern” View
Object == Collection Of (Related)
Behaviors
Methods == Behavior

19. “Modern” View
Object == Collection Of (Related)
Behaviors
Methods == Behavior
Properties == Details Of Behavior

20. Classic View == “(conceptually) is a”
Modern View == “behaves as a”

21. interface Number {
function getValue();
function __toString();
function add(Number $n);
function subtract(Number $n);
function equals(Number $n);
function isLessThan(Number $n);
function isGreaterThan(Number $n);
}

22. Number
IntegerFloat Decimal
longshort long long
unsigned signed

23. But Wait!

24. We Don’t Even
Need Inheritance

25. All We Need Is
Polymorphism
And Encapsulation

27. Polymorphism
Behavior Is Determined Dynamically
“Dynamic Dispatch”

28. Procedural Code
if ($a instanceof Long) {
return new Long($a->getValue() + 1);
} elseif ($a instanceof Float) {
return new Float($a->getValue() + 1.0);
} elseif ($a instanceof Decimal) {
return new Decimal($a->getValue() +
1.0);
}

29. Polymorphic Code
return $int->add(new Integer(1));

30. Polymorphic Code
class Integer implements Number {
public function add(Number $a) {
return new Integer(
$this->getValue() +
(int) $a->getValue()
);
}
}

31. Polymorphic Code
class Float implements Number {
public function add(Number $a) {
return new Float(
$this->getValue() +
(float) $a->getValue()
);
}
}

32. Encapsulation
Behavior Is Completely Contained By
The Object’s API
(Information Hiding)

33. Procedural Code
if (5 == $number->value) {
print “Number Is 5”;
} else {
print “Number Is Not 5”;
}

34. Encapsulated Code
if ($number->equals(new Integer(5))) {
print “Number Is 5”;
} else {
print “Number Is Not 5”;
}

35. Encapsulated Code
class Decimal implements Number {
protected $intValue;
protected $exponent;
public function equals(Number $a) {
if ($a instanceof Decimal) {
// Compare Directly
} else {
// Cast
}
}
}

36. Behavior Is
Defined By The
API

37. Two Types Of Primitive APIs
Interfaces (Explicit)

38. Two Types Of Primitive APIs
Interfaces (Explicit)
Duck Typing (Implicit)

39. If an Object Is A
Collection Of
Behaviors...

40. What Is A
Collection Of
Classes/Objects?

41. APIs
Method

42. APIs
Method MethodMethod
Class

43. APIs
Method MethodMethod
Class ClassClass
Package

44. APIs
Method MethodMethod
Class ClassClass
Package PackagePackage
Library

45. APIs
Method MethodMethod
Class ClassClass
Package PackagePackage
Library
Framework
LibraryLibrary

47. What Makes A
Good API?

48. A Good API
Does One Thing

49. A Good API
Never Changes

50. A Good API
Behaves Like Its
Contract

51. A Good API
Has A Narrow
Responsibility

52. A Good API
Depends Upon
Abstractions

53. And That’s
SOLID
Code

54. S - Single Responsibility Principle
O-
L -
I -
D-
A Good API
Does One
Thing

56. S - Single Responsibility Principle
O- Open / Closed Principle
L -
I -
D-
A Good API
Never Changes

58. S - Single Responsibility Principle
O- Open / Closed Principle
L - Liskov Substitution Principle
I -
D-
A Good API
Behaves Like
Its Contract

62. S - Single Responsibility Principle
O- Open / Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D-
A Good API
Has A Narrow
Responsibility

64. S - Single Responsibility Principle
O- Open / Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D- Dependency Inversion Principle
A Good API
Depends Upon
Abstractions

66. S - Single Responsibility Principle
O- Open / Closed Principle
L - Liskov Substitution Principle
I - Interface Segregation Principle
D- Dependency Inversion Principle

67. Note That SOLID
Does Not Dictate
What Is Good OOP

68. SOLID Emerges
From Good OOP

70. So, What Makes
A Bad API?

71. Global Variables
(Spooky Action
At A Distance)

72. Depending On
Specifics Of An
Implementation

73. Hidden
Dependencies

74. Unhealthy Focus
On Performance

75. Poorly Named
APIs

76. Duplication

77. And That’s
STUPID
Code

78. S - Singletons
T -
U -
P -
I -
D-
Global Variables
(Spooky Action
At A Distance)

80. S - Singletons
T - Tight Coupling
U -
P -
I -
D-
Depending On
Specifics Of An
Implementation

82. S - Singletons
T - Tight Coupling
U - Untestable Code
P -
I -
D-
Hidden
Dependencies

84. S - Singletons
T - Tight Coupling
U - Untestable Code
P - Premature Optimization
I -
D-
Unhealthy Focus
On Performance

86. S - Singletons
T - Tight Coupling
U - Untestable Code
P - Premature Optimization
I - Indescriptive Naming
D-
Poorly Named
APIs

88. S - Singletons
T - Tight Coupling
U - Untestable Code
P - Premature Optimization
I - Indescriptive Naming
D- Duplication
Duplication
Duplication
DuplicationDuplication
Duplication
Duplication
Duplication
Duplication

90. S - Singletons
T - Tight Coupling
U - Untestable Code
P - Premature Optimization
I - Indescriptive Naming
D- Duplication

91. STUPID
Embodies
Lessons Learned
From Bad OOP

92. What Good OOP Gives You
Modular Code
Reusable Code
Extendable Code
Easy To Read Code
Maintainable Code
Easy To Change Code
Easy To Understand Code
Clean Abstractions (mostly)

93. What Good OOP Costs You
Tends To Have More “Layers”
Tends To Be Slower At Runtime
Tends To Have Larger Codebases
Tends To Result In Over-Abstraction
Tends To Require More Effort To Write
Tends To Require More Tacit Knowledge

94. Let’s Look At
Some Code!

95. interface Car {
public function turnLeft();
public function turnRight();
public function goFaster();
public function goSlower();
public function shiftUp();
public function shiftDown();
public function start();
}

96. interface Steerable {
public function steer($angle);
}
interface Acceleratable {
public function accelerate($amt);
}
interface Shiftable {
public function shiftDown();
public function shiftUp();
}

97. interface Transmission {
public function getNumberOfGears();
public function getGear();
public function shiftToNeutral();
public function shiftToReverse();
public function shiftToGear($gear);
}
interface Manual extends Transmission {
public function engageClutch();
public function releaseClutch();
}
interface Automatic extends Transmission {
public function shiftToDrive();
}

98. Principle Of
Good
Enough

104. Anthony Ferrara
joind.in/8907
@ircmaxell
blog.ircmaxell.com
me@ircmaxell.com
youtube.com/ircmaxell