> Make your dependencies constructor args, then you can "inject" whatever the hell you like that conforms to the expected type. You can stick @Autowired on the

> Make your dependencies constructor args, then you can "inject" whatever the hell you like that conforms to the expected type. You can stick @Autowired on the constructor if you like, go nuts. But even without, well hell, you might not actually need that DI framework, and it's still in a testable space. Yes, this is exactly what I mean, the amount of wrong stuff that is in the constructor makes me believe DI is a solution for something else. Infinite amount of times have I encountered stuff in the constructor that shouldn't be there. Object A has a constructor with a bunch of dependencies, one of them is Object B. The proper way is for Object B to use object A instead. Blindly injecting everywhere is my problem with DI. Without these frameworks one would see that dependencies flow in a different direction if proper interfaces are defined. For example, React Context and useEffect hook is implicit DI yet people have no idea it's DI and I see codebases using React + DI framework instead. The only DI magic is the topological sort of dependencies and automatic construction. That stuff is 20 lines of additional code so that React.Context and useEffect work the same way.