2. The Dependency Inversion Principle
“High-level modules should not depend on low-level
modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should
depend on abstractions.”
The “Plugin Principle”
4. Outline
“Good” and “Bad” Design
Cohesion and Coupling
Inversion of Control
What is it?
Code Examples
Plugins
Conclusions
5. Characteristics of “Bad” Design
Rigidity:
Difficult to change because a change affects other parts
Fragility:
One change causes unexpected breaks
Immobility:
Difficult to reuse – tied to specific implementation
6. The Big Ones (Good Code)
High Cohesion
Low Coupling
9. Coincidental Cohesion
Grouped at random, nothing relates the parts
Eg. Frequently used functions grouped in a
class called “Utils”
10. Logical Cohesion
Grouped because they are logically
categorized to do the same thing even if
they are fundamentally different
Eg. Grouping IO functions
15. Example of Low Cohesive Code
Included are 35+ functions that provide you with the ability
to [use] a nicely formatted var dump, validate emails, generate
random strings, flatten an array, pull a single column out of a
multidimensional array and much more!
Util::ity.php – every programmers little buddy
16. Coupling
● Content Coupling
● Control Coupling
● Stamp Coupling
● Data Coupling
● Message Coupling
Better
http://www.codeodor.com/index.cfm/2009/6/17/Strive-for-low-coupling-and-high-cohesion-What-does-that-even-mean/2902
17. Content Coupling
One class directly manipulates another's
data, so a change in the data means a
change in the other class too
Two modules share the same global data
(e.g. a global variable). Changing the
shared resource implies changing all the
modules using it
18. Control Coupling
One module controlling the logic of another,
by passing it information on what to do
(e.g. passing a what-to-do flag)
25. What is Inversion of Control (IOC)
“Moving the decision of which concrete
class to use away from the part of the
system which uses it”
Flexibility!
43. “Divide by Boundaries, then Invert
the Dependencies that cross those
Boundaries”
Uncle Bob - Clean Coders Video “Dependency Inversion Principle”
The “Plugin Principle”
I love theory of programming
I’m a perfectionist, I look for most efficient ways of coding
Implementing a prototype in Web
Ask the audience
Coincidental – Grouped at random, nothing relates the parts, eg Frequently used functions
Logical – Grouped because they are logically categorized to do the same thing even if different, eg grouping IO functions (url is different to local file)
Procedural – Grouped by order of when things happen, eg checking file permissions then opening it
Communicational – Grouped because they operate on the same data
Functional - Grouped because they all contribute to a single well-defined task of the module (Single Responsibility Principle in Action!)
Remember Rigidity and Fragility?
Flow of Dependencies is opposite to Flow of Control
Remember the DI Principle:
High-level modules should not depend on low-level modules. Both should depend on abstractions.
Abstractions should not depend on details. Details should depend on abstractions.
There are different types of Dependency Injection, Constructor Injection is simplest.
Other ways:
Factory Method
Services Locator
Interface Injection
Count the dependencies.
Step 1: Create objects elsewhere
Now how many dependencies does the class have?
Plugins are perfect examples of IOC
Boundaries? - Enable reusability, because things are modular
Invert Dependencies? - Enable interchangablility by allowing mix and match (“plugin principle”)
How does IOC help?
How do we do it?
When should we apply it?
Theoretical: Whenever one class depends on another.
Practical: Pick clear boundaries and decouple them