KEMBAR78
Dependency injection with Symfony 2 | PPTX
Dependency Injection and
       Symfony
Introduction
Cameron Manderson
Developer, Director of Flint, Melbourne Symfony2 Organiser




cameronmanderson@gmail.com
Follow: @cammanderson
www.linkedin.com/in/cameronmanderson
Topic Highlight
• More in-depth look at the background of
  “Dependency Injection”
• Aiming to uncover in Symfony
  – Modularity in our implementation
  – Loose decoupling of dependencies
  – Managing scope and access to dependencies
Background
Some terminology
• Dependency
  – Something that is required by another object to
    fulfill its function
• Dependent
  – A client object that needs a dependency in order
    to perform its function
Shown easiest like this..

Dependent           Dependency


            Like…

 Emailer            Spell Checker
Example in code
This seems fine.. Right?
What about English or French?
Can we test it was called? – no…
We need an approach to handling these
           dependencies.
      We need looser coupling.
Dependency Injection



So what is Dependency Injection?
Dependency Injection
Dependency Injection
“A design pattern whose purpose is to improve the
testability of, and simplify deployment of components”

Essentially something that takes care of creating and
linking our objects

Involves 3 parts
• Our 2 objects; dependency and dependent
• And.. An Injector to instantiate objects at runtime
Example
Injector configures our objects at runtime,
figuring out the order of creation
                                 Injector reads the
                                 dependencies, and
                   Injector      creates and stiches
                                 them together




      Dependent               Dependency
So.. Why dependency injection?
• Why do we need better management?
  – Applications are full of objects and dependencies
     • We want automation of construction
     • We want easy management of objects
     • We don’t want hundreds of Factories
  – Hard to manage those dependencies
     • Applications become tightly coupled to one-another
     • Difficult to swap out implementations
     • Manage configuration of those dependencies
Pre-dependency injection
• How do we currently do it?
  – Hand-written construction
  – Using Factory patterns
Hand-construction
Factory
Enter Dependency Injection
• Offset the instantiation of those objects to
  something else, as well as the dependencies
  – Some behind the scenes magic
  – Read a definition of how these dependencies
    should be handled
  – Create the objects and associate their
    dependencies
• Scope (talk about later)
Injector/idioms
• Simple logic:
  – Can it create the object yet? If there is a
    dependency, go create it.. Loop etc.
• Essentially… a role to..
  – Creating the “new” object when needed
  – Managing the dependencies
     • Constructor Injection
     • Setter Injection
Injector Configuration
Plain PHP files..
Constructor Injection
• Constructor injection has dependencies in the
  constructor
  – Need to create the dependencies for the
    dependent first
  – Inject them through the constructor
Setter Injection
• Create the object first and inject the
  dependents through methods (setters)
Some stuff to be careful of…
• Circular dependencies
  – Oops. Be careful. (There are ways to handle.. Not
    yet in Symfony)

                        A


           C                         B
So how does this help?
• We are all about building modular
  applications
  – Decoupling dependencies
  – Making clear what the intent of the module is
  – Separation of concerns
  – Improve testability
Decoupling
• Reduce the specific hard-value reliance
  – Facilitate swapping out new implementations
  – Reduce that complexity
  – Hopefully reduce the risk..
Make clear what it is
• We want clear intent to our application
  – Make it easy to use and modify
  – “Program to contract”
     • Implement interfaces that clearly defines the intent of
       our code
Separation of concerns
• We want to better encourage design to
  separate the concerns in our application
  – Discreet features
• Application Logic vs Infrastructure Logic

                   Application


                  Infrastructure
Testability
• Keep it clean
  – Avoiding static calls or singletons
  – Out of container testing easy
  – Easy to test concerns individually and manually
    define dependencies and mocks
We are lazy
• It is much easier utilising a dependency
  injector to handle creating objects and handle
  those dependencies than to worry about
  implementing patterns and configuration
  yourself.
Basics… check!
• That’s the theory
  – Dependencies exist in our application
  – Dependency injection assists creating and
    managing those objects
  – Makes our life easier
• Let’s talk about Symfony and Services..
Symfony Service Architecture
• Symfony is an Event Driven application
• Also provides a dependency injector and
  service locator
The Service
Service
  – An object that performs a well defined function
    when called upon
  – Separated from other parts of the application
  – Implements an action
     • e.g. Template Renderer, Mail, etc
Configuring the Injector
Service Locator (Service Container)
• Assists by providing a way to access services
  by “key”
Finding Keys
• Might be a problem?
• Symfony makes it easy, use the CLI
Further stuff to read…
• Topics
  – Aliasing
  – Public and Private
  – Specifying parameters in your config.yml


• http://symfony.com/doc/current/book/service
  _container.html
Wrapping it up
• My experience with it has been that:
  – You are encouraged to write services that others
    can use and extend
  – Your applications are much easier to test
  – Scope is much easier to manage
  – It encourages others to implement their own
    domain logic when needed, thanking you how
    easy it is to implement their own part. ;-)
Conclusion
• Covered the concepts of dependency injection
  – The problem
  – Using dependency injection to remove (code)
• Showed how it applies in Symfony
  – Better decoupling, modularity and reuse

Dependency injection with Symfony 2

  • 1.
  • 2.
    Introduction Cameron Manderson Developer, Directorof Flint, Melbourne Symfony2 Organiser cameronmanderson@gmail.com Follow: @cammanderson www.linkedin.com/in/cameronmanderson
  • 3.
    Topic Highlight • Morein-depth look at the background of “Dependency Injection” • Aiming to uncover in Symfony – Modularity in our implementation – Loose decoupling of dependencies – Managing scope and access to dependencies
  • 4.
  • 5.
    Some terminology • Dependency – Something that is required by another object to fulfill its function • Dependent – A client object that needs a dependency in order to perform its function
  • 6.
    Shown easiest likethis.. Dependent Dependency Like… Emailer Spell Checker
  • 7.
  • 8.
  • 9.
  • 10.
    Can we testit was called? – no…
  • 11.
    We need anapproach to handling these dependencies. We need looser coupling.
  • 12.
    Dependency Injection So whatis Dependency Injection?
  • 13.
    Dependency Injection Dependency Injection “Adesign pattern whose purpose is to improve the testability of, and simplify deployment of components” Essentially something that takes care of creating and linking our objects Involves 3 parts • Our 2 objects; dependency and dependent • And.. An Injector to instantiate objects at runtime
  • 14.
    Example Injector configures ourobjects at runtime, figuring out the order of creation Injector reads the dependencies, and Injector creates and stiches them together Dependent Dependency
  • 15.
    So.. Why dependencyinjection? • Why do we need better management? – Applications are full of objects and dependencies • We want automation of construction • We want easy management of objects • We don’t want hundreds of Factories – Hard to manage those dependencies • Applications become tightly coupled to one-another • Difficult to swap out implementations • Manage configuration of those dependencies
  • 16.
    Pre-dependency injection • Howdo we currently do it? – Hand-written construction – Using Factory patterns
  • 17.
  • 18.
  • 19.
    Enter Dependency Injection •Offset the instantiation of those objects to something else, as well as the dependencies – Some behind the scenes magic – Read a definition of how these dependencies should be handled – Create the objects and associate their dependencies • Scope (talk about later)
  • 20.
    Injector/idioms • Simple logic: – Can it create the object yet? If there is a dependency, go create it.. Loop etc. • Essentially… a role to.. – Creating the “new” object when needed – Managing the dependencies • Constructor Injection • Setter Injection
  • 21.
  • 22.
  • 23.
    Constructor Injection • Constructorinjection has dependencies in the constructor – Need to create the dependencies for the dependent first – Inject them through the constructor
  • 24.
    Setter Injection • Createthe object first and inject the dependents through methods (setters)
  • 25.
    Some stuff tobe careful of… • Circular dependencies – Oops. Be careful. (There are ways to handle.. Not yet in Symfony) A C B
  • 26.
    So how doesthis help? • We are all about building modular applications – Decoupling dependencies – Making clear what the intent of the module is – Separation of concerns – Improve testability
  • 27.
    Decoupling • Reduce thespecific hard-value reliance – Facilitate swapping out new implementations – Reduce that complexity – Hopefully reduce the risk..
  • 28.
    Make clear whatit is • We want clear intent to our application – Make it easy to use and modify – “Program to contract” • Implement interfaces that clearly defines the intent of our code
  • 29.
    Separation of concerns •We want to better encourage design to separate the concerns in our application – Discreet features • Application Logic vs Infrastructure Logic Application Infrastructure
  • 30.
    Testability • Keep itclean – Avoiding static calls or singletons – Out of container testing easy – Easy to test concerns individually and manually define dependencies and mocks
  • 31.
    We are lazy •It is much easier utilising a dependency injector to handle creating objects and handle those dependencies than to worry about implementing patterns and configuration yourself.
  • 32.
    Basics… check! • That’sthe theory – Dependencies exist in our application – Dependency injection assists creating and managing those objects – Makes our life easier • Let’s talk about Symfony and Services..
  • 33.
    Symfony Service Architecture •Symfony is an Event Driven application • Also provides a dependency injector and service locator
  • 34.
    The Service Service – An object that performs a well defined function when called upon – Separated from other parts of the application – Implements an action • e.g. Template Renderer, Mail, etc
  • 35.
  • 36.
    Service Locator (ServiceContainer) • Assists by providing a way to access services by “key”
  • 37.
    Finding Keys • Mightbe a problem? • Symfony makes it easy, use the CLI
  • 38.
    Further stuff toread… • Topics – Aliasing – Public and Private – Specifying parameters in your config.yml • http://symfony.com/doc/current/book/service _container.html
  • 39.
    Wrapping it up •My experience with it has been that: – You are encouraged to write services that others can use and extend – Your applications are much easier to test – Scope is much easier to manage – It encourages others to implement their own domain logic when needed, thanking you how easy it is to implement their own part. ;-)
  • 40.
    Conclusion • Covered theconcepts of dependency injection – The problem – Using dependency injection to remove (code) • Showed how it applies in Symfony – Better decoupling, modularity and reuse