Tweet
Tweet

Slide 1

Slide 1 text

Dependency Injection and Dependency Inversion in PHP @J7mbo

Slide 2

Slide 2 text

Your goal on a project?

Slide 3

Slide 3 text

Professional Integrity

Slide 4

Slide 4 text

“I want a plumber who takes a pride in his work, who bothers to learn and gain experience, who takes what he does seriously” “I expect to pay extra for expertise, but it's a wise investment compared to hiring a cowboy plumber and having to pay later to fix up the botch job he left me with”

Slide 5

Slide 5 text

“Integrity is "doing the right thing even when no one is looking", and I see Software Craftsmanship as striving for integrity in the systems we create.” David Starr (elegantcode.com)

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

A little bit about me…

Slide 8

Slide 8 text

OOP, DI, DiP, IoC, DIC, SOLID, WTF

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

No content

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

Object Instantiation

Slide 18

Slide 18 text

Object Instantiation Http Request

Slide 19

Slide 19 text

Object Instantiation Http Request Disgusting DOM Searching

Slide 20

Slide 20 text

Object Instantiation Http Request Disgusting DOM Searching Sorting Algorithm

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

Please be True…

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

Asking for objects to be passed in is Dependency Injection Calling Code

Slide 26

Slide 26 text

Inversion of Control

Slide 27

Slide 27 text

I have to mock this… And this… This too.. srsly

Slide 28

Slide 28 text

Calling getContents() will now return this HTML Passing in my $fakeClient

Slide 29

Slide 29 text

Dependency Injection provides Control

Slide 30

Slide 30 text

1 year later…

Slide 31

Slide 31 text

“High-level modules should not depend on low-level modules. Both should depend on abstractions”

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

“Polymorphism is the provision of a single interface to entities of different types”

Slide 35

Slide 35 text

Recap • Dependency Injection is simply passing in object dependencies as parameters instead of instantiating them in the object using them

Slide 36

Slide 36 text

Recap • Dependency Injection is simply passing in object dependencies as parameters instead of instantiating them in the object using them • Doing this gives you Inversion of Control, as the control over object creation is no longer delegated to the object using them

Slide 37

Slide 37 text

Recap • Dependency Injection is simply passing in object dependencies as parameters instead of instantiating them in the object using them • Doing this gives you Inversion of Control, as the control over object creation is no longer delegated to the object using them • If you use don’t do this, other people will hate you because they can’t mock your objects easily in their tests (so your code is not testable)

Slide 38

Slide 38 text

Recap • Dependency Injection is simply passing in object dependencies as parameters instead of instantiating them in the object using them • Doing this gives you Inversion of Control, as the control over object creation is no longer delegated to the object using them • Using interfaces, we can adhere to the Dependency Inversion Principle and depend on abstractions • If you use don’t do this, other people will hate you because they can’t mock your objects easily in their tests (so your code is not testable)

Slide 39

Slide 39 text

Recap • Dependency Injection is simply passing in object dependencies as parameters instead of instantiating them in the object using them • Doing this gives you Inversion of Control, as the control over object creation is no longer delegated to the object using them • Using interfaces, we can adhere to the Dependency Inversion Principle and depend on abstractions • Code always starts off procedural, and builds objects up before executing them in an object oriented manner • If you use don’t do this, other people will hate you because they can’t mock your objects easily in their tests (so your code is not testable)

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

Bootstrap (Procedural) Framework (Object Oriented) (hopefully) Dev Code (Object Oriented) (hopefully) Composition Root Objects built

Slide 42

Slide 42 text

Bootstrap (Procedural) Framework (Object Oriented) (hopefully) Dev Code (Object Oriented) (hopefully) Composition Root Objects built Match route to controller + action Create controller Run action with any request parameters

Slide 43

Slide 43 text

Bootstrap (Procedural) Framework (Object Oriented) (hopefully) Dev Code (Object Oriented) (hopefully) Composition Root Objects built Match route to controller + action Create controller Run action with any request parameters Developer creates a controller Does whatever they want

Slide 44

Slide 44 text

Framework (Object Oriented) (hopefully)

Slide 45

Slide 45 text

Framework (Object Oriented) (hopefully)

Slide 46

Slide 46 text

Dependency Injection Container (DiC)

Slide 47

Slide 47 text

Get the Conference object here

Slide 48

Slide 48 text

External requirements should be visible from an object’s constructor and method signatures

Slide 49

Slide 49 text

Bootstrap (Procedural) Framework (Object Oriented) (hopefully) Dev Code (Object Oriented) (hopefully) Composition Root Objects defined and registed in container ‘Object Graph’

Slide 50

Slide 50 text

Bootstrap (Procedural) Framework (Object Oriented) (hopefully) Dev Code (Object Oriented) (hopefully) Composition Root Objects defined and registed in container Match route to controller + action Container Creates controller (with dependencies) Container runs action with any request parameters ‘Object Graph’

Slide 51

Slide 51 text

Bootstrap (Procedural) Framework (Object Oriented) (hopefully) Dev Code (Object Oriented) (hopefully) Composition Root Objects defined and registed in container Match route to controller + action Container Creates controller (with dependencies) Container runs action with any request parameters Developer creates a controller DI’s registered dependencies Does whatever they want ‘Object Graph’

Slide 52

Slide 52 text

No content

Slide 53

Slide 53 text

No content

Slide 54

Slide 54 text

No content

Slide 55

Slide 55 text

Create the PhpNw15Conference object

Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

Automatic Injection for concrete classes

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

See ‘Conference’ Create ‘PhpNw15Conference’

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

Bootstrap (Procedural) Framework (Object Oriented) (hopefully) Dev Code (Object Oriented) (hopefully) Composition Root Relationships (object graph) defined in configuration file Match route to controller + action Injector Creates controller (with dependencies) Developer creates a controller DI’s registered dependencies Does whatever they want

Slide 67

Slide 67 text

Dev Code (Object Oriented) (hopefully) Developer creates a controller DI’s registered dependencies Does whatever they want

Slide 68

Slide 68 text

Dev Code (Object Oriented) (hopefully) Developer creates a controller DI’s registered dependencies Does whatever they want

Slide 69

Slide 69 text

Dev Code (Object Oriented) (hopefully) Developer creates a controller DI’s registered dependencies Does whatever they want • Not coupled to container • Remove code / move code about at any time • Concentrate on writing SOLID code

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

• Your objects should specify external requirements needed in their constructor and method signatures

Slide 73

Slide 73 text

• Your objects should specify external requirements needed in their constructor and method signatures • Dependency Injection is simply passing in external requirements as parameters

Slide 74

Slide 74 text

• Your objects should specify external requirements needed in their constructor and method signatures • Dependency Injection is simply passing in external requirements as parameters • Using interfaces for functionality that might change provides polymorphism (switch out concrete implementation any time)

Slide 75

Slide 75 text

• Your objects should specify external requirements needed in their constructor and method signatures • Dependency Injection is simply passing in external requirements as parameters • Using interfaces for functionality that might change provides polymorphism (switch out concrete implementation any time) • Depending on abstractions rather than concretes (interfaces), and having your object graph composed ‘higher’ in the codebase (composition root), provides Inversion of Control and helps you adhere to the Dependency Inversion Principle

Slide 76

Slide 76 text

What next? AOP and PHP7’s Anonymous Classes

Slide 77

Slide 77 text

‘Decorate’ existing Controller Delegate controller method call,
 but add additional functionality (logging)

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

No content

Slide 80

Slide 80 text

No content

Slide 81

Slide 81 text

Anonymous Class Automatic
 Decoration

Slide 82

Slide 82 text

How can I apply this? • Choose a framework that supports automatic recursive DI • Choose a micro-framework or components that allow you to substitute the ‘controller resolver’ to provide this • Legacy codebase? Don’t have to use an auto-injector, just design your interfaces well adhere to DIP when you can • In your next project, make this a primary consideration of your software architecture

Slide 83

Slide 83 text

Why bother?

Slide 84

Slide 84 text

• The ‘gang of four book’ (GoF) • The Clean Coder (Robert C. Martin) • Post your code on CodeReview (and survive)

Slide 85

Slide 85 text

@J7mbo https://joind.in/talk/view/15431