I think dependency injection (DI) is great but I was thinking about how often I’ve been using it recently and thinking I might be overusing it. DI has become far more popular with all the container frameworks around, but a container isn’t necessary to use the DI pattern, though it is a bit more typing and wiring things together without a container.

Before I started working on projects with a container of some sort I made infrequent use of the DI pattern. Once the container came along I was using it all the time to the point where I didn’t use the new keyword at all. Why? Did I really need all this extra flexibility provided by DI? Was I just using it because it looks clean? Depending on an interface can never be bad right? I was thinking to myself that if I didn’t have this container and had to do ‘pure DI’ - would I be injecting this? Probably not.

There’s no doubt that using the DI pattern adds lots of flexibility to our code, but do we always need that flexibility? Can that flexibility actually make things more difficult?

I’ve been writing a lot of tests recently and trying out TDD on the simpler features I’ve been working on. The strategy I’ve been using while testing is to mock all the dependencies each class has and test each class. Sounds okay right? Except, each set of tests is now coupled to a single class because I’ve exclusively used DI for all my classes. That’s not a good thing.

Sometimes testing a single layer (class) is good and exactly what you want to do, but that’s not what we want to be doing all of the time. If you test every single layer/class imagine what happens as soon as you need to modify one of these layers?

Best case: You’ve modified the interface so a bunch of your tests no longer compile - you fix the tests and mocks. You lost the ability to rely on the tests however.

Worst case: You modify the behaviour of the class and update the tests for that class - but forget to update all the mocks. Easy mistake to make - the tests on other classes will still pass and compile fine so it won’t be obvious. Yet, the communication points between these classes have changed but our tests don’t reflect the change that has occurred. Now we have untested behaviour in our system that we believe to be tested. This doesn’t tend to occur in strongly typed languages because the types restrict the behaviour of a method much more tightly, but can be a problem in JavaScript for example. Even in a strongly typed language, sometimes the test data that your mocks return simply isn’t realistic anymore.

In any case - there’s a maintenance overhead attached, something we want to reduce as much as possible. Any class that is injected into another must (up for debate) have a set of tests associated with it, you might want that or it might be an unnecessary cost that you don’t need.

Dependencies don’t always need to or should be injected, sometimes using the new keyword is okay. Knowing what to inject and what not to inject is something I can’t quite define concretely right now. What I am certain of is that not every class you create needs the suffix ‘Service/Helper’ or needs to be registered in your container as a singleton each and every time.