If you have a class whose constructor depends on an instance of something else, you can instantiate that first and pass it on.
That's all there's to it.
You can do DI in your own startup code and have some logic in there that substitutes mocks when running under test. Or you could change the logging when debug is enabled. Hardly rocket science. If you can write code, you can write the startup code.
If your team likes patterns, dont mention dependency injection unless you're confident it wont get replaced with the framework of the day.
Frameworks turn your DI code into highly complicated configuration. The end result is a giant lump of code whose only achievement is hiding the new operator and possibly also someones job security.
> Now dependency injection, that's some magical bullshit right there.
I see you there! Joking aside, for me, I also struggled a lot with DI when I first saw it in Java. The ridiculous frameworks that hid all of the details drove me crazy. Even Google Guice was supposed to be more clear, but it was never as clear as... Eventually, I settled on hand-writing the wiring in one giant 1,000+ line function that builds the entire object graph on start-up. Then I could really understand DI because you could actually read (and debug) the code doing the "wiring" (building the object graph).
If you have a class whose constructor depends on an instance of something else, you can instantiate that first and pass it on.
That's all there's to it.
You can do DI in your own startup code and have some logic in there that substitutes mocks when running under test. Or you could change the logging when debug is enabled. Hardly rocket science. If you can write code, you can write the startup code.
If your team likes patterns, dont mention dependency injection unless you're confident it wont get replaced with the framework of the day.
See https://www.jamesshore.com/v2/blog/2023/the-problem-with-dep...
Frameworks turn your DI code into highly complicated configuration. The end result is a giant lump of code whose only achievement is hiding the new operator and possibly also someones job security.
I see you there! Joking aside, for me, I also struggled a lot with DI when I first saw it in Java. The ridiculous frameworks that hid all of the details drove me crazy. Even Google Guice was supposed to be more clear, but it was never as clear as... Eventually, I settled on hand-writing the wiring in one giant 1,000+ line function that builds the entire object graph on start-up. Then I could really understand DI because you could actually read (and debug) the code doing the "wiring" (building the object graph).