Dependencies or Codependencies?

Before I start this discussion I want to refer you to my previous rambling, This is My Tool as it may keep your head from exploding. 

There are many tools that, while founded with good intention, create more messes than they solve. This article will look at dependency injection (DI). In my experience, I have never seen a project that uses DI that was not a complicated, horrific mess.

I will attempt to catalogue how these messes manifest, reasons they seem to be inevitable and solutions/patterns to prevent their occurrence.

What is it

To be honest I never considered dependency injection to be a thing in and of itself. I use it frequently as part of the Inversion of Control (IOC) pattern by injecting concrete instances of an abstract class into an object through its constructor.

This is incredibly useful for testing code that accesses external resources, abstracting dependencies so you can switch out implementations. For example, it is very useful to be able to swap Google AI, ChatGPT, OpenAI, etc. during development and testing.

With emergence of Spring Boot, Lombok, etc. it seems to have taken a life  of its own. Teams use these frameworks to ‘wire up’ all objects. The results are frequently horrifying.

The intent (no free lunch)

The intent of DI is pretty straight forward: to decouple the construction of a needed object from its use. 

I find the misuse of DI is invariably linked to one problem. Programmers never stop to ask the question: “Now why in tarnation would I want to do that?” They see it as a cool new tool (refer to the aforementioned article) and use it everywhere.

They forget that all tools have overhead. Does the savings from using this tool overcome this cost or are you simply adding more to the accidental complexity of your project.

The costs

I find two main costs of DI. First, you typically don’t know your type until runtime and second, you don’t know life cycle of the object you are using. This makes maintaining state rather difficult.  These costs are a direct result of the tool itself. 

Arthur Riel, in his seminal work “Object Oriented Design Heuristics’ described how objects get the objects they use. One of the five ways was “God gives it to you”. This is the problem. Can you trust the god who gave it to you. I mean, which god Thor or Loki?

One project I worked on, no-one remembered how a particular set of objects were being injected. It was problematic because it was unknown whether the calls to these objects were synchronous or asynchronous. It took me days to figure it out. After searching through config files, configuration classes, under my desk (I mean it had to come from somewhere) I launched the debugger to see what concrete class was being injected, then reversed engineered where it came from.

If we had simply instantiated the class and passed it through the constructor, this search would have taken seconds.

Why

I had to go through several projects to figure out why anyone would use this. I mean there is a compelling argument to use spring boot or similar to set up a web service or bind a db implementation. And as long as you keep the bindings simple and minimal there is no significant overhead. 

Interestingly, in every project that used DI before I got on it, the framework was used everywhere. These projects were ungainly, overly complex, buggy and unscalable.

Why would anyone do this to themselves? I can think of two reasons.

First, many developers like the declarative nature of the DI tools. They seem to think that annotations to sew things together is simpler, hence it goes everywhere. The trouble is that declarative languages do not scale in terms of features. 

It might be fine when you can remember all of the objects, but as the project grows it becomes impossible to track all of the relationships.

Second, many people don’t understand the principals of object oriented design. I had one developer tell me that he did not like OOD because object structures are tall, skinny, deep things. When you instantiate and object it creates objects that creates objects. Using DI he was able to expose all of the objects.

The fundamental simplifying principle of OOD is containment. Successfully calling a constructor means that that object and all of the contained objects are valid and ready to chose. These DI tools blow away this assumption and condition.

This leads to exponential costs of change. I don’t care about, within reason, the cost of implementing the first few features. The real question is how expensive is the thousandth or the ten thousandth. The only reason we design / architect is to keep the cost of change flat. 

DI tools are at odds with this goal. It is essential that if you are using DI it is forced to the outside of you business logic. The layer it lives in will suffer from all of the above effects, but if it is small it will be useable.