The issue with this, in my experience, is that if you don't understand the driving principles behind DI patterns (prefer to depend on an interface or set of beh

The issue with this, in my experience, is that if you don't understand the driving principles behind DI patterns (prefer to depend on an interface or set of behaviors, prefer to be given something that satisfies that dependency instead of instantiating it yourself, with the aim of not doing things you aren't responsible for), you can end up with what amounts to either rather messy global state, or with systems that are still very highly coupled but have good paint. I can't help but see discussions about DI as suffering from sounding fancier than it is and also from less-experienced devs thinking that they must be writing "correct" code because it has the general shape of the DI pattern they read about. If it were my choice, I'd ditch the terminology and best practices all together in favor of active practice critically thinking about the dependencies, responsibilities, and assumptions of code being written or read.