2 ms·
DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and default
by jimbokun 3y ago
DI in something like Spring, for example, can make it extremely hard to track where a given dependency is coming from. With the use of annotations and defaults and properties on annotations for selecting a dependency, to sometimes autogenerated classes for which there is no source code.
I would much rather have a few lines of straight forward code that set up dependencies explicitly, than deal with opaque semantics and mysterious incantations.
- eximius 3y agoI've never really had that trouble. There are typically relatively few places that 1. a given interface is provided via a DI module 2. said modules are included in a binary With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search. I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.
- jimbokun 3y agoThe autogenerated class with no source code was not a hypothetical example. This was something I saw cause a problem in production, where the source code in the stack trace didn't exist.
- eximius 3y agocode generation is a mostly disjoint topic from DI. Granted, some solutions like https://github.com/google/wire https://github.com/google/wire use code generation, but you're exactly right about their pitfalls. If your dev environment doesn't have good support for generated code, it is a nightmare. If you can goto-definition the generated code, then it is suddenly feasible, but perhaps still a bad choice. But the DI frameworks I've used are typically just... normal code files. Uber/fx, Go/Guice, etc