4 ms·
I never understood this. DI is for deciding program behavior. That should be a user choice. I don't understand how final users are supposed to (1) write XML fil
by dullgiulio 7y ago
I never understood this. DI is for deciding program behavior. That should be a user choice. I don't understand how final users are supposed to (1) write XML files instead of providing simple human readable CLI flags, (2) know the program internals and being able to type in fully qualified class names.
$ ./my-server -reporting=email
vs
setting com.mycompany.package.subpackage.di.providers.abstract.ReportingProvider to com.mycompany.package.subpackage.di.providers.impl.EmailReportingProviderImpl.
The whole DI is a wrong concept. Dependencies should be instantiated at top level (main function) and explicitly passed down the call graph as interface instances.
DI breaks the call graph with (configurable) side effects. If you pass down dependencies explicitly you don't even need mocking frameworks for testing.
- spand 7y agoYou are just refuting your own straw man. Passing dependencies also qualifies as DI and is for the benefit of the developer. Maybe you are only talking about DI frameworks or containers in which case I share some skepticism but in general the concept of DI is pretty sound.