Dependency Injection: a discussion of the pros and cons

[tony_marston404]

@cpradio

DI has been a huge benefit to me and the way that I code as I can write better tests. Better tests means I can churn out changes quicker, as I simply write a new test for the upcoming change, write the code, and then verify all tests still pass.

If you are happy with DI then go for it. I personally do not see the benefit of DI in the kind of applications which I write, and I resent the attitude of the “paradigm police” that just because THEY like DI that I should too, and if I don’t follow their “advice” (which I interpret as diktats) then I must be some sort of heretical deviant.

@cpradio

Since going this route, the number of bugs produced from my changes have been zero. We’ve found issues with requirements or maybe a requirement was written incorrectly, but from what the requirements had, their test cases/scenarios, and the final result of development, zero bugs.

I don’t need DI to produce bug free software. I don’t need DI to add enhancements to my software. My point is that the effort of refactoring my entire codebase, which contains over 2,000 units of work, would be absolutely enormous. For what benefit? To make it easier to do something which I never have to do.

@cpradio

I unfortunately can’t say the same for some of the legacy systems that our devs do not write tests for, are riddled with tightly coupled dependencies, and although they “function”, the amount of time spent on fixing bugs, adding/updating functionality there is cost heavy and typically results in a new bug or two or dozen that most of the time gets caught in QA, but have edge cases that make it to Production as well.

Even DI cannot help with badly structured or badly written code. It is not a “magic bullet” that can automatically solve all your problems. All it does is move the problem from one area to another, and in the process it introduces more complexity, more levels of indirection, more code to execute, more code to read and understand, and the potential for more bugs.

@cpradio

That may be my experience and your experience may be entirely different, but if I were to start a project again from the ground up, I’d still follow a Test Driven Development path and ensure that my components can be fully tested and that would mean the usage of DI as a must.

Using DI is an option, not a requirement. TDD is an option, not a requirement. I have been happily designing and developing software for several decades without using those options, and I do not believe that using those options would make either the design process or the development process any quicker or better. That is my opinion, and I’m sticking to it.