I'm writing software that needs to be fairly configurable in nature. At this point what that means is that it first reads in a users configuration file and then builds the objects it needs based on that configuration.

As a result of creating objects based on a users desired functionality it seems to me that Inversion of Control isn't really feasible which makes dependency injection seem impossible.

As an example let's say I need to tell a program to process some data in a certain way. I can configure it when it starts up to process the data with processors A or B or C or even A and C. If I have to construct these objects based on a users configuration then I don't know how to allow for dependency injection.

Is this a scenario where dependency injection isn't appropriate or are there different patterns (which I am unaware of) that solve this problem and allow for dependency injection? If there are other patterns what are they?

I think the root of my question is this:

If I have dependencies A, B, and C and a user can configure the software at startup to use any number of these dependencies (A, A, B or A, B, C or A, C or A, C, C, etc.) how can I do dependency injection when the objects are not singletons and I need to change the necessary dependencies at startup time?

  • Many dependency injectors are also configurable at startup. That's kind of the whole point; otherwise, why bother with dependency injection? – Robert Harvey Aug 10 '16 at 15:06
  • @RobertHarvey I understand your point, perhaps I'm thinking about this wrong. I've edited my question to try and add more clarity, but I may still be missing some basic understanding, in which case please point that out to me. – binarylegit Aug 10 '16 at 15:35
  • What does "when the objects are not singletons and I need to change the necessary dependencies at startup time" mean? My suggestion would be to provide a way for the user to configure the features that they want, and then you write some custom logic that works out whatever dependencies you need to implement those features at runtime and hand those dependencies to your DI container. – Robert Harvey Aug 10 '16 at 15:37
  • If A, B, and C are features, and I need to run two distinct instances of feature A and one instance of feature B how can I do that utilizing Dependency Injection? Is it necessary to have a layer that does not sit within the scope of the DI and manually requests Dependencies from the DI container? – binarylegit Aug 10 '16 at 16:20
  • 1
    Is your problem A) you don't know how to change the bindings in your DI framework based on runtime configuration, B) you don't know how to deal with requiring multiple instances of the same class or C) something else entirely? – Winston Ewert Sep 9 '16 at 16:42

How is this a problem? Dependency injection is just passing in the dependencies to the things that need them. It is occasionally not appropriate, but those cases are where the dependencies are strongly held and have subtle semantics. This is not that case.

If you're talking about Inversion of Control containers, that would make more sense. Some are unwieldy when the components aren't fixed or known ahead of time. Some are more flexible in that regard. You might just need to investigate what your options are.

Or you can get rid of them and do DI in other ways (constructor or property injection, service locators, custom IoC containers, etc).

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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