Re:Dependency injection in Go with Uber-go/fx
by staticassertion on Sunday February 27, 2022 @02:45PM
(#30491803)
This is pretty much what I don't get. DI by construction is trivial and has all of the benefits of a DI framework. DI frameworks just let you move some things around, which is mostly confusing.
[ Parent
| on HN ]
Re:Dependency injection in Go with Uber-go/fx
by ceras on Sunday February 27, 2022 @09:50PM
(#30495769)
As someone who's liked using DI frameworks, I'm curious: if you do it manually, as your codebase gets large, doesn't it get harder to "plumb" a new object that needs to get used somewhere at a deep level? This seems like it'd get more unwieldy when refactoring.
I've never worked in a large codebase that did this manually so I'm not sure what it looks like. The large codebases I've seen that don't use DI have used something like a service locator, singletons, or constructed everything where it was needed (and used extensive mocking framework functionality for testing).
Re:Dependency injection in Go with Uber-go/fx
by staticassertion on Monday February 28, 2022 @10:07AM
(#30500592)
All object creation is in one place - main. So no, I should never have to go deep anywhere.
Re:Dependency injection in Go with Uber-go/fx
by lucasyvas on Monday February 28, 2022 @10:49AM
(#30501159)
This is my take as well. Plus, if you are plumbing something that deep, the odds that your design is total shit is approaching 100%.
Manual DI reveals problems like this way earlier.
DI frameworks, IMO, are some of the most useless around. Solution seeking a problem.