> I don't think I've ever injected a non-functional dependency Logging is the classic example. Or the data service provider, or CXF-type stuff > Use a factory

> I don't think I've ever injected a non-functional dependency Logging is the classic example. Or the data service provider, or CXF-type stuff > Use a factory or default arguments I think that's the main point. Framework-managed DI puts a stop to the factory madness that you always ended up with back in the old Java or C++ world. > Have the default constructor setup the concrete dependency and use the extra constructor for your unit tests This will work for a while, but when you start needing to test complex flows, you're going to end up having classes calling classes calling classes, having multiple constructors will become unmanageable. > DI tools introduce accidental complexities that outweigh their benefits in the simplest use cases I totally, fully, definitely agree with you! The heavy tools such as Spring or EE6 are ugly, frustrating behemoths with absolutely no advantages for small or even medium developments. But as soon as it starts becoming a 40MY+ project I find you can't avoid them :(