Inversion of control

1,243 views

Published on

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

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,243
On SlideShare
0
From Embeds
0
Number of Embeds
24
Actions
Shares
0
Downloads
29
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • 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
  • 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?

    ×