Dependency injection in Go with Uber-go/fx

Re:Dependency injection in Go with Uber-go/fx by azth on Sunday February 27, 2022 @02:43PM (#30491789)

Because golang doesn't have constructors, you're forced to implement functions that mimic them yourself. And the language still doesn't prevent you from directly instantiating the struct yourself, meaning it is always possible to bypass the "constructor functions". This is quite terrible and opens up your code to errors.

Furthermore, DI frameworks also usually have lifecycle management, which is quite handy in many cases.

[ Parent | on HN ]

Re:Dependency injection in Go with Uber-go/fx by twodave on Sunday February 27, 2022 @05:19PM (#30493280)

Fine, but that applies to even data structures and other domain types, which even in a more classically-OO language you wouldn’t pipe through a DI framework. I think DI as a code organization concept is great, but if I have to write a factory for every struct anyway then it’s not any harder to simply use those as a rule and define module boundaries sensibly as a way to determine which code should be using new vs the factory methods.

You have a good point wrt lifecycle management, but I feel like that’s actually a separate class of problem.

[ Parent | on HN ]