mirror of
https://github.com/codeguy/php-the-right-way.git
synced 2025-08-09 15:36:36 +02:00
Revisions
This commit is contained in:
committed by
Josh Lockhart
parent
5e0f12004c
commit
aaebe65095
@@ -4,5 +4,10 @@ title: Dependency Injection
|
||||
|
||||
# Dependency Injection {#dependency_injection_title}
|
||||
|
||||
Dependency Injection is a basic concept that solves a complex problem. As a software design pattern it is being adopted in
|
||||
some way or another by all major PHP projects.
|
||||
From [Wikipedia](http://en.wikipedia.org/wiki/Dependency_injection):
|
||||
|
||||
> Dependency injection is a software design pattern that allows the removal of hard-coded dependencies and makes it
|
||||
> possible to change them, whether at run-time or compile-time.
|
||||
|
||||
This quote makes the concept sound much more complicated than it actually is. Dependency Injection is providing a component
|
||||
with it's dependencies either through constructor injection, method calls or the setting of properties. It is that simple.
|
||||
|
@@ -4,15 +4,11 @@ isChild: true
|
||||
|
||||
## Basic Concept {#basic_concept_title}
|
||||
|
||||
From [Wikipedia](http://en.wikipedia.org/wiki/Dependency_injection):
|
||||
We can demonstrate the concept with a simple, yet naive.
|
||||
|
||||
> Dependency injection is a software design pattern that allows the removal of hard-coded dependencies and makes it
|
||||
> possible to change them, whether at run-time or compile-time.
|
||||
|
||||
This quote makes the concept sound much more complicated than it actually is. Dependency Injection is providing a component
|
||||
with it's dependencies either through constructor injection, method calls or the setting of properties. It is that simple.
|
||||
|
||||
We can demonstrate the concept with a simple, yet naive, example.
|
||||
Here we have a `Database` class that requires an adapter to speak to the database. We instantiate the
|
||||
adapter in the constructor and create a hard dependency. This makes testing difficult and means the `Database` class is
|
||||
very tightly coupled to the adapter.
|
||||
|
||||
{% highlight php %}
|
||||
<?php
|
||||
@@ -31,9 +27,7 @@ class Database
|
||||
class MysqlAdapter {}
|
||||
{% endhighlight %}
|
||||
|
||||
Here we have a `Database` class that requires an adapter to speak to the database. We instantiate the
|
||||
adapter in the constructor and create a hard dependency. This code can be refactored to use Dependency Injection
|
||||
and therefore loosen the dependency.
|
||||
This code can be refactored to use Dependency Injection and therefore loosen the dependency.
|
||||
|
||||
{% highlight php %}
|
||||
<?php
|
||||
|
@@ -5,7 +5,12 @@ isChild: true
|
||||
## Complex Problem {#complex_problem_title}
|
||||
|
||||
If you have ever read about Dependency Injection then you have probably seen the terms *"Inversion of Control"* or *"Dependency Inversion Principle"*.
|
||||
These are the complex problems that Dependency Injection solves, or to be more precise, elegantly solves.
|
||||
These are the complex problems that Dependency Injection solves.
|
||||
|
||||
### Inversion of Control
|
||||
|
||||
Inversion of Control is as it says, "inverting the control" of a system by keeping organisational control entirely separate from our objects.
|
||||
In terms of Dependency Injection, this means loosening our dependencies by controlling and instantiating them elsewhere in the system.
|
||||
|
||||
For years, PHP frameworks have been achieving Inversion of Control, however, the question became, which part of control
|
||||
are you inverting, and where to? For example, MVC frameworks would generally provide a super object or base controller that other
|
||||
@@ -15,6 +20,8 @@ dependencies, this method simply moved them.
|
||||
Dependency Injection allows us to more elegantly solve this problem by only injecting the dependencies we need, when we need them,
|
||||
without the need for any hard coded dependencies at all.
|
||||
|
||||
### Dependency Inversion Principle
|
||||
|
||||
Dependency Inversion Principle is the "D" in the S.O.L.I.D set of object oriented design principles that states one should
|
||||
*"Depend on Abstractions. Do not depend on concretions."*. Put simply, this means our dependencies should be interfaces/contracts or abstract
|
||||
classes rather than concrete implementations. We can easily refactor the above example to follow this principle.
|
||||
|
Reference in New Issue
Block a user