4 ms·

> Dependency Injection has a fancy name that makes some developers uncomfortable, but it's really just all about making the code easier to test. It's not just

> Dependency Injection has a fancy name that makes some developers uncomfortable, but it's really just all about making the code easier to test. It's not just a fancy name. I'd argue it's a confusing name. The "$25 name for a 5c concept" quote is brilliant. The name makes it sound like it's some super complicated thing that is difficult to learn, which makes it harder to understand. I would say "dynamic programming" suffers the same problem. Maybe "monads". How about we rename it? "Generic dependencies" or "Non hard-coded dependencies" or even "dependency parameters"?

kevmo314 1y ago
“Global variables that can pass code review”
layer8 1y ago
The name is confusing because originally [0] it was exclusively about dynamic injection by frameworks. Somehow it morphed into just meaning suitable constructor parameters, at least in some language communities. I like “dependency parameters”. Dependencies in that sense are usually what is called service objects, so “service parameters” might be even clearer. [0] https://www.martinfowler.com/articles/injection.html#FormsOfDependencyInjection https://www.martinfowler.com/articles/injection.html#FormsOf...
akoboldfrying 1y ago
I third "dependency parameters". It concisely describes what the actual thing is, and isn't intimidating. And yes, even though some languages/frameworks allow deps to be "passed in" via mechanisms that aren't technically parameters (like member variables that are just somehow magically initialised due to annotations), doing that only obfuscates control flow and should be avoided IMHO.
ulrikrasmussen 1y ago
I think the "injection" is referring to a particular style of frameworks which rely on breaking language abstractions and modifying otherwise private fields to provide dependencies at runtime. I really, really, REALLY dislike that approach and therefore also dislike the name "dependency injection". Why not call it "dependency resolution"? The only problem frameworks solve is to connect a provider of thing X with all users of thing X, possibly repeating this process until all dependencies have been resolved. It also makes it more clear that this process is not about initialization and lifecycling, it is only about connecting interfaces to implementations and instantiating them. Edit: The only DI framework I have used and actually kind of like is Dagger 2, which resolves all dependencies at compile time. It also allows a style of use where implementation code does not have to know about the framework at all - all dependency resolution modules can be written separately. All other runtime DI frameworks I have used I have hated with a passion because they add so much cognitive overhead by imposing complex lifecycle constraints. Your objects are not initialized when the constructor has finished running because you have to somehow wait for the DI framework to diddle the bits, and good luck debugging when this doesn't work as expected.

kevmo314 1y ago

“Global variables that can pass code review”

layer8 1y ago

The name is confusing because originally [0] it was exclusively about dynamic injection by frameworks. Somehow it morphed into just meaning suitable constructor parameters, at least in some language communities. I like “dependency parameters”. Dependencies in that sense are usually what is called service objects, so “service parameters” might be even clearer. [0] https://www.martinfowler.com/articles/injection.html#FormsOfDependencyInjection https://www.martinfowler.com/articles/injection.html#FormsOf...

akoboldfrying 1y ago

I third "dependency parameters". It concisely describes what the actual thing is, and isn't intimidating. And yes, even though some languages/frameworks allow deps to be "passed in" via mechanisms that aren't technically parameters (like member variables that are just somehow magically initialised due to annotations), doing that only obfuscates control flow and should be avoided IMHO.

ulrikrasmussen 1y ago

I think the "injection" is referring to a particular style of frameworks which rely on breaking language abstractions and modifying otherwise private fields to provide dependencies at runtime. I really, really, REALLY dislike that approach and therefore also dislike the name "dependency injection". Why not call it "dependency resolution"? The only problem frameworks solve is to connect a provider of thing X with all users of thing X, possibly repeating this process until all dependencies have been resolved. It also makes it more clear that this process is not about initialization and lifecycling, it is only about connecting interfaces to implementations and instantiating them. Edit: The only DI framework I have used and actually kind of like is Dagger 2, which resolves all dependencies at compile time. It also allows a style of use where implementation code does not have to know about the framework at all - all dependency resolution modules can be written separately. All other runtime DI frameworks I have used I have hated with a passion because they add so much cognitive overhead by imposing complex lifecycle constraints. Your objects are not initialized when the constructor has finished running because you have to somehow wait for the DI framework to diddle the bits, and good luck debugging when this doesn't work as expected.