How to you use DI without DI framework in a reasonably complex project

dependency-injectioninversion-of-control

edit

I asked this question not because this is my opinion, but because I am trying to understand someone else's. Personally I prefer IoC via DI (in my specific case Simple Injector) but not everybody shares this opinion and I am trying to get some insight as to how maintainable code would be without DI.

end edit

I've been wondering about this for a few weeks now, but I can't seem to find a decent answer.

How can a developer write maintainable code while adhering to SOLID principles, without using a DI framework?

Some example code to make this somewhat less abstract:

class ImageProcessor: IImageProcessor
{
    public ImageProcessor() { ... }
}

class ImageUploader: IImageUploader
{
    public ImageUploader(IImageProcessor processor) { ... }
}

class ImageService
{
    public ImageService(IImageUploader uploader) { ... }
}

class ImageController
{
    public ImageController()
    {
        var imageService = new ImageService(new ImageUploader(new ImageProcessor()));
    }
}

Each class uses DI to get his dependencies injected via the constructor except the endpoint, in this case the ImageController which creates everything.

Suppose that the ImageProcessor now requires a new dependency, for example a IConfig to determine image dimensions.

class ImageProcessor
{
    public ImageProcessor(IConfig config) { ... }
}

class ImageController
{
    public ImageController()
    {
        var imageService = new ImageService(new ImageUploader(new ImageProcessor(new Config())));
    }
}

The main problem that I see is that all complexity and dependencies bubble up to every endpoint, every controller that uses this ImageProcessor and every consumer (e.g. batch processing).

The coupling of those inner dependencies would skyrocket because everyone knows about them.

Am I missing something?

How can I write maintainable code without a DI framework, while still trying to use DI?

Best Answer

The main problem that I see is that all complexity and dependencies bubble up to every endpoint, every controller that uses this ImageProcessor and every consumer (e.g. batch processing).

And how does a DI framework solve that? It reduces the amount of code you need to write, but the complexity is still there. You still have all of the dependencies, and you still have all of the coupling. The top layer is using the lower layers and something has to know how to make them. Using a DI framework just hides it away and makes it harder to debug.

But if you need to make a change, you're still at the mercy of the coupling.

As others have mentioned, I wouldn't do that sort of constructor chaining, but the general approach is fine. Classes take interfaces, whose implementation is supplied by some external actor. Having the controller know about that is maybe forcing it to have multiple responsibilities, but a DI framework is just one way to separate the "knows how to build dependencies" responsibility from the usual controller work.

Related Solutions

Dependency Injection/IoC container practices when writing frameworks

The only legitimate dependency injection anti-pattern that I'm aware of is the Service Locator pattern, which is an anti-pattern when a DI framework is used for it.

All of the other so-called DI anti-patterns that I've heard about, here or elsewhere, are just slightly more specific cases of general OO/software design anti-patterns. For instance:

Constructor over-injection is a violation of the Single Responsibility Principle. Too many constructor arguments indicates too many dependencies; too many dependencies indicates that the class is trying to do too much. Usually this error correlates with other code smells, such as unusually long or ambiguous ("manager") class names. Static analysis tools can easily detect excessive afferent/efferent coupling.
Injection of data, as opposed to behaviour, is a subtype of the poltergeist anti-pattern, with the 'geist in this case being the container. If a class needs to be aware of the current date and time, you don't inject a DateTime, which is data; instead, you inject an abstraction over the system clock (I usually call mine ISystemClock, although I think there's a more general one in the SystemWrappers project). This is not only correct for DI; it is absolutely essential for testability, so that you can test time-varying functions without needing to actually wait on them.
Declaring every life cycle as Singleton is, to me, a perfect example of cargo cult programming and to a lesser degree the colloquially-named "object cesspool". I've seen more singleton abuse than I care to remember, and very little of it involves DI.
Another common error is implementation-specific interface types (with strange names like IOracleRepository) done just to be able to register it in the container. This is in and of itself a violation of the Dependency Inversion Principle (just because it's an interface, does not mean it's truly abstract) and often also includes interface bloat which violates the Interface Segregation Principle.
The last error I usually see is the "optional dependency", which they did in NerdDinner. In other words, there is a constructor that accepts dependency injection, but also another constructor that uses a "default" implementation. This also violates the DIP and tends to lead to LSP violations as well, as developers, over time, start making assumptions around the default implementation, and/or start new-ing up instances using the default constructor.

As the old saying goes, you can write FORTRAN in any language. Dependency Injection isn't a silver bullet that will prevent developers from screwing up their dependency management, but it does prevent a number of common errors/anti-patterns:

...and so on.

Obviously you don't want to design a framework to depend on a specific IoC container implementation, like Unity or AutoFac. That is, once again, violating the DIP. But if you find yourself even thinking about doing something like that, then you must have already made several design errors, because Dependency Injection is a general-purpose dependency-management technique and is not tied to the concept of an IoC container.

Anything can construct a dependency tree; maybe it's an IoC container, maybe it's a unit test with a bunch of mocks, maybe it's a test driver supplying dummy data. Your framework shouldn't care, and most frameworks I've seen don't care, but they still make heavy use of dependency injection so that it can be easily integrated into the end user's IoC container of choice.

DI isn't rocket science. Just try to avoid new and static except when there's a compelling reason to use them, such as a utility method that has no external dependencies, or a utility class that could not possibly have any purpose outside the framework (interop wrappers and dictionary keys are common examples of this).

Many of the problems with IoC frameworks come up when developers are first learning how to use them, and instead of actually changing the way they handle dependencies and abstractions to fit the IoC model, instead try to manipulate the IoC container to meet the expectations of their old coding style, which would often involve high coupling and low cohesion. Bad code is bad code, whether it uses DI techniques or not.

Java Dependency Injection – Using Guice to Replace Service Locator Implementation

Both Game and WorldFactory class would have FileSystem as their dependencies. Below is an example of dependency injected through a constructor (it is also possible to inject them directly into fields):

@Inject
public Game(FileSystem fs) { }

@Inject
public WorldFactory(FileSystem fs) { }

You could then write a provider inside one of your modules that would construct and return a new FileSystem instance:

@Provides
FileSystem provideFileSystem() {
    return ServiceLocator.getService(FileSystem.class);
}

Once you treated other services similarly, you will be able to completely remove your reliance on ServiceLocator, moving the service-creating code directly into providers.

So then you get an odd instance where the constructor of a game entity requires that you pass an instance to the AudioSystem to it which it can play audio through. It just gets very messy with all these objects/services being explicitly passed around.

Not only this is not messy, this is the whole point of dependency injection. The thing is, however, that you should never explicitly pass all those instances manually. Instead, you can have Guice reconstruct the dependency graph from them and construct all necessary, intermediate objects (or obtain them in any other way you specify in your providers). On your side, creating the final object is just a matter of calling Injector.getInstance(Foo.class) -- it's up to Guice to figure out how to satisify the dependencies.

Best Answer

Related Solutions

Dependency Injection/IoC container practices when writing frameworks

Java Dependency Injection – Using Guice to Replace Service Locator Implementation

Related Topic