#1
  1. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2013
    Location
    Melbourne, Australia
    Posts
    13
    Rep Power
    0

    Varying Definitions of Dependency Injection


    I've been programming for nearly 30 years and professionally for about 10, but dependency injection as a pattern is a fairly new topic for me; probably because I'm mostly self-taught.

    While researching best practices and available dependency injection libraries for Unity, I found several references to things that I would not associate with dependency injection. For example, having a factory singleton to get required objects: Dependency injection - Unify Community Wiki. Or in another case, having a library that silently injects dependencies based on config file or other startup code (e.g. Ninject, Suice).

    In my understanding, dependency injection is simply requiring code that instantiates and/or uses and object, etc. to supply the dependencies, rather than having the objects find/create their own. And the purpose of this is to make unit testing simpler by increasing separation of concerns. In particular, it was my understanding that dependency injection was in compete opposition to the use of singletons and globals; a thought that is contrary to the definitions referenced above.

    Have I misunderstood dependency injection, or are these other definitions incorrect?
  2. #2
  3. Lazy Moderator
    Devshed Supreme Being (6500+ posts)

    Join Date
    Mar 2007
    Location
    Washington, USA
    Posts
    16,325
    Rep Power
    9645
    Dependency injection at its core is about objects not needing to know how to create their dependencies. Beyond that it's subject to interpretation and technical practicalities.

    There are two basic approaches:
    1. You pass in the dependencies through methods (like a constructor). This is like a "traditional" dependency injection scheme. It's fine to use, but isn't as easy to work with as other approaches since you'll be passing things like factory and database objects all over your code. Sometimes that's not a problem, but it can be a hassle to use throughout a project.
    2. You give the class knowledge about where to get their dependencies. It's not quite like 100% DI but it still meets the requirement of not knowing how to create dependencies - in the "what concrete class/what configuration" sense, not in the literal sense. Which means, if you think about it, that factories are like DI themselves: calling code doesn't know quite what to create or how to create it.

    The Unity thing is doing the latter. The class does not knowledge about the dependency itself but does know about where to get it.
  4. #3
  5. No Profile Picture
    Registered User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2013
    Location
    Melbourne, Australia
    Posts
    13
    Rep Power
    0
    Ah. Thank you. Yes, that makes sense. I'm very much used to the, as you say, "traditional" scheme. I think the confusion comes from being introduced to it as an alternative to global objects, singletons and static factories.

    By reducing it to it's basics, you've made it all make much more sense. Thanks again.

IMN logo majestic logo threadwatch logo seochat tools logo