0

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?

Improve this question
10
  • Many dependency injectors are also configurable at startup. That's kind of the whole point; otherwise, why bother with dependency injection?
    – Robert Harvey
    Commented Aug 10, 2016 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
    Commented Aug 10, 2016 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
    Commented Aug 10, 2016 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
    Commented Aug 10, 2016 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
    Commented Sep 9, 2016 at 16:42

1 Answer 1

Reset to default
2

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).

Improve this answer

Your Answer

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