Zend Di in ZF 2.0

Software Engineer at Zend
Oct. 19, 2011

More Related Content


Zend Di in ZF 2.0

  1. October 2011 ZendDi
  2. Who Am I? •Ralph Schindler (ralphschindler) Software Engineer on the Zend Framework team •At Zend for almost 4 years •Before that TippingPoint/3Com Programming PHP for 13+ years Live in New Orleans, LA. •Lived in Austin, Tx for 5 years My background with Di •I was part of the original roundtable 3yr ago @ zendcon –Fabien + Stephan + Myself 2
  3. First Some Background •Background Di Definitions Some generic patterns 3
  4. Dependency Injection •Subject matter expert: Martin Fowler not the only one, but has a nice take on it • injection.html 4
  5. Di vs. DiC •Di is a pattern This is non-negotiable DI is about Inversion Of Control (IoC) –sometimes not an easy concept to grasp for beginner and intermediate developers •DiC is a tool Subject to a developer’s or a group of developers requirements I.E.: no formal definition •as such, lots of frameworks provide this in some way shape or form 5
  6. Important Fowler Quote •“Inversion of control is a common feature of frameworks, but it's something that comes at a price. It tends to be hard to understand and leads to problems when you are trying to debug. So on the whole I prefer to avoid it unless I need it. This isn't to say it's a bad thing, just that I think it needs to justify itself over the more straightforward alternative.” 6
  7. Di: In a Nutshell •Obligatory: 7
  8. Di’s Misguided Argument •Testing everyone quotes this as the argument for dependency injection •correct for silo’d development •if you are the only consumer of your code too much emphasis here 8
  9. The Better Di Argument •Makes it easy for developers to swap out implementation •Paddy Brady: ... “it helps ensure source code can be maintained in a highly decoupled state. Which make it easier to subclass the Zend Framework to death, and modify it’s components before use.” 9
  10. Di Identified Types •Constructor Favored by PicoContainer derivatives •Setter Favored by Spring Container derivatives 10
  11. Di 3rd Injection Type •Interface Injection but first as segue ... 11
  12. What is an Interface •A contract that forces subtypes to conform to particular method signatures so that objects can exhibit particular behaviors 12
  13. Interfaces •Interface best practices No constructors No static methods •Why? Because interfaces are about “alternate implementations” •PHP allows statics and constructors in interfaces for better or worse 13
  14. Interfaces explained •A better way to think about it Interfaces are about contracts in behavior between developers Point in case, search for “friends” in this page: • 14
  15. Interfaces in practice 15
  16. Back To Interface Injection •First and foremost: a communication tool •Form of setter injection (or, injection via method) •The dependency is implied by the interface and the injection point is forced by the interface Always part of the type’s hierarchy •Rely’s on a managing/consuming object/ framework for execution - or a really strict developer 16
  17. Interface Injection Example 17
  18. Interface Injection Pattern •Not formal / it is semi-de-facto •Interface injection is tricker to understand without context •(Semi) Well known pattern at play the “Aware” interface name 18
  19. Interface Injection Downside •At the application layer, it leads to having to write and consume lots of interfaces to get things sorted out 19
  20. Interface Injection Downside 20
  21. Constructor vs. Setter Injection •Constructor Pro: object in ready state Con: there is a param per dependency •too busy of an object? or just right? Con: dependencies are not polymorphic Pro/Con: dependencies can (not?) be swappable after instantiation Pro: object declares complexity up front Con: can lead to cyclical dependencies 21
  22. Constructor vs. Setter Injection •Constructor continued: •Constructors are not subject to Liskov Substitution Principle (Ctor is not part of the type in question) –In other languages ctors are static 22
  23. Constructor vs. Setter Injection •Setter Pro: clear injection points for each dependency Con: consumer has to be very honest about injecting all dependencies Con: construct is not up front about required dependencies •hard to distinguish optional vs. required dependencies –is this really such a thing? 23
  24. Misconceptions? •(SL) Service Locators !== (DiC) Dependency Injection Containers •But DiC == SL DiC’s can be the foundation of consumed for service location 24
  25. Typical Dependency Injection Graph 25
  26. Service Locator •It is understood that services to be locator aware •Pros: not all code paths in the consuming object might use all the dependencies •Example: controller •Cons: service locator becomes the dependency 26
  27. Service Locator Graph 27
  28. •ZendDi 28
  29. Why Di For Zend •Considering a DiC is a first world problem for developers •Why did we create this component? You’re afraid of “new”? You asked for it •Having a DI Container that tries to understand your code makes you code better 29
  30. Questions Raised •But is it really possible to force developers to write better code? •How do we look at a use case and tell if the DiC is falling short, or the developer is writing bad code? There is a fine line 30
  31. DiCs Out There - Not PHP •Java Spring, PicoContainer •.net Spring.Net, StructureMap, Unity, Castle’s Windsor 31
  32. ZendDi perspective •we support both: "This issue has led to a lot of debate between the various teams who provide dependency injectors as part of their frameworks. However it seems that most people who build these frameworks have realized that it's important to support both mechanisms, even if there's a preference for one of them." •-Martin Fowler 32
  33. Developing ZendDi •Development of ZendDi 33
  34. Goals •Find a way to produce a DiC that works for PHP developers and all their “tendencies” very hard to identify •Performant - as best as possible we have no persistent memory •The same or less code required than actually just writing the code in the first place 34
  35. A Note on DI and Performance •Di is just code, it is a performant as not practicing Di so long as you’re still using the same number of dependencies/objects •DiC is not performance friendly! Front loading workflow, structural needs NOT Hello World friendly! 35
  36. ZendDi Parts •Two main components Definition Instance Configuration •Runtime concerns 36
  37. ZendDi Definition •Goals Explain what the code looks like, what it expects Identify which classes have dependencies Identify injection points Names for all the moving parts 37
  38. ZendDi Definition •Instantiation: Constructor (new keyword) Callback (factory pattern) •Via object factory •Via static factory method 38
  39. ZendDi Definition •From a very fundamental level, injection always comes in the two forms Via constructor params Via method injection •We (currently) do not support public property setting 39
  40. ZendDi Definition •Naming dependency/configuration entry points Is an object expected? Is there a type hint? •Where does it originate from? Is a scalar expected? Is it optional? 40
  41. ZendDi Configuration •Goals Encapsulate runtime data required to wire instances •Could be environment specific (dev. different than production) Be able to identify which objects fulfill a dependency (preferred types) 41
  42. Definition & Configuration •A better understanding: Definitions can be shipped with your code, they are independent of how they are used Configuration is what is expected of anyone consuming ZendDi 42
  43. Building Definitions •At Runtime (on-demand) Great for development, terrible for production, esp. with annotations turned on •Compiler (Reflection+Scanner) (yesterday’s talk on ZendCode) Compiled into an array; used with ArrayDefinition •By-Hand ClassDefinition BuilderDefinition 43
  44. Demo Time •Live Demo Time •Code:  Examples Uses ZF2 Beta Phars 44
  45. Other Containers •Yadif (beberlei) •Pimple (Fabien Potencier) •Symfony Di Container for 5.3 •PicoContainer more than 5 years old 45
  46. ZendDi Todo •Further divorce the Service Locator / Dependency Injection Container •Service locators can be defined by callbacks (closures) 46
  47. Thanks! •Questions, Concerns? •Thanks! 47

Editor's Notes

  1. \n
  2. \n
  3. \n
  4. \n
  5. \n
  6. Is he talking about the practice or the container?\n
  7. \n
  8. \n
  9. \n
  10. \n
  11. How many of you use interfaces currently in your code in your orgnaization\n
  12. \n
  13. \n
  14. \n
  15. \n
  16. \n
  17. \n
  18. \n
  19. point in case on next slide:\n
  20. \n
  21. \n
  22. \n
  23. \n
  24. \n
  25. \n
  26. \n
  27. \n
  28. \n
  29. \n
  30. \n
  31. \n
  32. \n
  33. \n
  34. \n
  35. \n
  36. \n
  37. \n
  38. \n
  39. \n
  40. \n
  41. \n
  42. \n
  43. \n
  44. \n
  45. \n
  46. \n
  47. \n