Hacker News Reader

Comment by jimbokun | Hacker News Reader

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.

View on HN

I'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.

The 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.

code generation is a mostly disjoint topic from DI. Granted, some solutions like 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

Reply on news.ycombinator.com