What is dependency injection
In: Technology
It’s a modern architecture choice.
In “normal” code, or the intuitive way people are taught, if a part of the code needs another thing, it is responsible for creating or getting that thing.
So, for example, if I’m writing code that calculates the total for an invoice, maybe I also want some code that knows how to calculate the tax for each item. That tax code is “a dependency” because my “bigger” piece of code depends on it.
In really old programs, all of that code would be in more or less the same place. But for about 60 years now code has been separated into what I will oversimplify and call “modules” so that bits of it can be used and reused in many parts of a program and/or tested by itself.
So in my code, I’d have a tax calculation module and my invoice calculation module depends on it. Without dependency injection, I’d do something language specific to make my invoice calculation code refer to the module. For example, in an OOP language I’d “create a tax calculator object”.
But WITH dependency injection, I’d instead write my invoice calculation module in a way that says, “I need someone ELSE to give me a tax calculation module to use.” That “someone else” is the thing that “injects” the dependency.
In physical terms, it’s like the difference between buying a computer and building a computer. Buying a computer is not having Dependency Injection. You get a pre-assembled computer. In some cases, you can DIY replace parts, but in cases like MacBooks you get what you get. Dependency Injection is more like building your own computer: you get to pick and choose each part and you know you’ll always be able to swap different parts in.
In practical terms it’s supposed to make large-scale programs a little easier to maintain by making them behave more like DIY computers than MacBooks. That way in theory if things change, the developer only has to change some “dependencies” and maybe not the modules that depend on them.
But there are some snarky people in this thread claiming it doesn’t work. What they’ve encountered is that it’s *hard* to write software that can be changed without a lot of effort. A lot of people have that attitude. My experience is those people don’t tend to work on software they have to keep changing for 15 years, so they don’t value practices that make very long-term maintenance easier at the cost of very short-term complexity. You can make a bigger mess with DI if you aren’t thinking hard. If you aren’t thinking hard you shouldn’t be programming.
That’s what architecture is in software: trading one kind of complexity for another we hope is better.
Latest Answers