Skip to content

Commit

Permalink
Revisions
Browse files Browse the repository at this point in the history
  • Loading branch information
happyaccidents authored and Josh Lockhart committed Feb 1, 2014
1 parent 5e0f120 commit aaebe65
Show file tree
Hide file tree
Showing 3 changed files with 20 additions and 14 deletions.
9 changes: 7 additions & 2 deletions _posts/06-01-01-Dependency-Injection.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.
16 changes: 5 additions & 11 deletions _posts/06-02-01-Basic-Concept.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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
Expand Down
9 changes: 8 additions & 1 deletion _posts/06-03-01-Complex-Problem.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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.
Expand Down

0 comments on commit aaebe65

Please sign in to comment.