Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
Loading in …5
×

# Inversion of control

1,387 views

Published on

A talk on Inversion of Control: what it is, how it helps and how to do it.

• Full Name
Comment goes here.

Are you sure you want to Yes No
Your message goes here
• Be the first to comment

### Inversion of control

1. 1. Inversion of Control And the Dependency Inversion Principle What’s Inversion?
2. 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”
3. 3. Why?
4. 4. Outline  “Good” and “Bad” Design Cohesion and Coupling  Inversion of Control What is it? Code Examples Plugins  Conclusions
5. 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. 6. The Big Ones (Good Code) High Cohesion Low Coupling
7. 7. Cohesion and Coupling
8. 8. Cohesion ● Coincidental cohesion ● Logical cohesion ● Procedural cohesion ● Communicational cohesion ● Functional cohesion Better http://www.codeodor.com/index.cfm/2009/6/17/Strive-for-low-coupling-and-high-cohesion-What-does-that-even-mean/2902
9. 9. Coincidental Cohesion Grouped at random, nothing relates the parts Eg. Frequently used functions grouped in a class called “Utils”
10. 10. Logical Cohesion Grouped because they are logically categorized to do the same thing even if they are fundamentally different Eg. Grouping IO functions
11. 11. Procedural Cohesion Grouped by order of when things happen Eg. Checking file permissions and then opening it
12. 12. Communicational Cohesion Grouped because they operate on the same data
13. 13. Functional Cohesion Grouped because they all contribute to a single well-defined task of the module Single Responsibility Principle in Action!
14. 14. Example of Low Cohesive code
15. 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. 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. 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. 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)
19. 19. Stamp (Data-Structured) Coupling Modules both use a common data structure and use only a part of it. Can lead to unexpected breaks when data structure changes
20. 20. Data Coupling Objects share data through parameters \$mailer = new Mailer(); \$mailer->sendEmail(\$to, \$from, \$body);
21. 21. Message Coupling Objects use a public interface to exchange messages (events, observer pattern)
22. 22. No Coupling Objects don’t know about each other and never communicate with each other.
23. 23. Example of Coupled code
24. 24. Inversion of Control
25. 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!
26. 26. What is Inversion of Control? Before After Inversion!
27. 27. Ok cool, How? 1. Create objects elsewhere (DI) o Constructor/Setter Injection 2. Depend on Abstractions (D in SOLID)
28. 28. First Example
29. 29. Back to the “Coupled” Code
30. 30. Step 1: Create objects elsewhere
31. 31. Step 2: Depend on Abstractions
32. 32. Bonus: Cleanup
33. 33. What did we win? Testability Reusability Flexibility DecoupledDecoupled
34. 34. Done! Dependencies are Inverted! Bonus: SRP?
35. 35. Bonus: The Single Responsibility Principle
36. 36. Another Example
37. 37. Another Example
38. 38. Step 1: Create objects elsewhere
39. 39. Step 2: Depend on Abstractions
40. 40. Bonus: Cleanup!
41. 41. Plugins
42. 42. Plugins Wow, it’s a Plugin!!!
43. 43. “Divide by Boundaries, then Invert the Dependencies that cross those Boundaries” Uncle Bob - Clean Coders Video “Dependency Inversion Principle” The “Plugin Principle”
44. 44. Conclusions
45. 45. Conclusions So we know how IOC helps… And we know how to do it… But when should we apply it? Hint: always
46. 46. References  http://martinfowler.com/bliki/InversionOfControl.html  http://martinfowler.com/articles/injection.html  https://leanpub.com/cleanphp  http://fabien.potencier.org/media/talk/2008/decouple-your-code-for-reusability-ipc-2008.pdf  https://gist.github.com/Integralist/5763515  http://www.codeodor.com/index.cfm/2009/6/17/Strive-for-low-coupling-and-high-cohesion-What-does-that-even-mean/2902 So, what was Inversion again? Questions?