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.

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.

  • 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?

×