0

What is the "essence" of dependency injection? Is it the idea of dynamically swapping out/in core logical/structural aspects of a program at runtime?

Traditionally, this is done in code via some DI container. For example, using Structure Map in C#:

container.For<ICacheService>().Use<InMemoryCache>();

However, I've written several programs which inject code via configuration, in XML. Something like:

<cacheServiceProvider use="My.Namespace.InMemoryCache, MyAssembly"/>

That config is iterated at startup, and the various classes are instantiated for use throughout the program.

Is it fair to say that this is a form of DI? "Dependency Injection by Configuration"? Or does DI require configuration in code and the use of some container system?

Are their other philosophical or conventional aspects required to say something is "dependency injected," or am I completely misunderstanding this?

Improve this question
3
  • 2
    If it had an official definition, it would probably be a lot less broad. I still have no idea if dependency injection includes simply passing arguments to constructors or if it only means that sort of configuration stuff which I assume gets translated into passing arguments to constructors.
    – Ixrec
    Commented May 27, 2016 at 11:45
  • What you are describing here is dependency inversion / inversion of control, rather than dependency injection. That latter is neatly summed up by @Julian Hayward's answer.
    – David Arno
    Commented May 27, 2016 at 12:51
  • @DavidArno Confusingly, inversion of control containers are a specific way of doing dependency injection, and dependency injection is a specific way of achieving inversion of control
    – Ben Aaronson
    Commented May 27, 2016 at 13:10

1 Answer 1

Reset to default
8

The essence is simply that given an object, you pass its dependencies to it rather than let it instantiate them itself.

How you achieve that, by containers, configuration, or any other means, is up to you.

Improve this answer
6
  • Do you have "pass dependencies" to every object every time they're created, or can those dependencies exist in a global state? So, you pass dependencies to the entire program, and expose them globally in such a way that multiple parts of that program can use them.
    – Deane
    Commented May 27, 2016 at 11:51
  • @Deane suppose you have a class Foo { List<Bar> bars; Baz baz; ... } without DI the constructor is public Foo() { bars = new ArrayList<Bar>(); baz = new SpecificBaz(); } and therefore the exact concrete subtype of List and Bar and Baz is tied to Foo. DI is allowing any List / Bar / Baz. All the other 'DI' stuff is just things trying to make life easier in that paradigm.
    – Caleth
    Commented May 27, 2016 at 12:14
  • +1. to answer @Deane-s comment: Implementing “dependency injection” means that the code has an api to handle "“dependency injection” (via constructor parameter, properties, methods,....). The DI container is responsible to handle the "global state" for the "entire program" (i.e. as a singleton or "every time they're created")
    – k3b
    Commented May 27, 2016 at 12:17
  • 1
    Note that for a small example, this will seem like a massive overkill. It is, but the benefit is that it forces you the programmer to think about compartmentalizing your code.
    – Caleth
    Commented May 27, 2016 at 12:23
  • 3
    I think that the very notion of tying the concept of DI to big XML configs, arcane conventions and all-around heavy frameworks is "harmful". It'd be like saying that "MVC is a project template by microsoft that requires you to name all your controllers 'NameController'"
    – sara
    Commented May 27, 2016 at 13:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.