I honestly don't think there even was a problem to be solved. Constructors could just accept their dependencies (interfaces) as parameters.
Dependency Injection with Go
21–26 of 26 posts
Re: Dependency Injection with Go
#22I honestly don't think there even was a problem to be solved. Constructors could just accept their dependencies (interfaces) as parameters.
On larger code bases it can help a lot. You get to a point where you need that config object over in some random function and you start weaving it through constructors. At which point a simple DI system really appeals.
DI code also tends to be more pleasant to test in my experience since it promotes loose coupling.
Re: Dependency Injection with Go
#23I honestly don't think there even was a problem to be solved. Constructors could just accept their dependencies (interfaces) as parameters.
On larger code bases it can help a lot. You get to a point where you need that config object over in some random function and you start weaving it through constructors. At which point a simple DI system really appeals. DI code also tends to be more pleasant to test in my experience since it promotes loose coupling.
Quite the contrary as repeatedly experienced in Java land.
Re: Dependency Injection with Go
#24I honestly don't think there even was a problem to be solved. Constructors could just accept their dependencies (interfaces) as parameters.
On larger code bases it can help a lot. You get to a point where you need that config object over in some random function and you start weaving it through constructors. At which point a simple DI system really appeals. DI code also tends to be more pleasant to test in my experience since it promotes loose coupling.
I believe there are other ways:
http://commandcenter.blogspot.com/2014/01/self-referential-f...
And you should probably avoid situations where you suddenly need config objects in 'random places'. This could be a symptom of chaotic API design. But then again, whatever works for you.
Re: Dependency Injection with Go
#25Went down this path already. It was OK for a while with a small codebase, but the problem is that you need to give up your simple direct Go code for magic reflection. I discovered there are better and more idiomatic ways to do this type if thing without resorting to dependency injection.
Strongly agree. A verbose `main` carries the benefit of being explicit and unambiguous. Components whose constructors take all of their dependencies are simple to reason about and straightforward to test. The code described in the article seems like it's burdened with patterns from other languages and ecosystems, and which are pretty nonidiomatic Go: "AppLoader"? The complexity of their final solution seems to be a r…
Yeah. I think the fear of a verbose `main` is wrong. It's OK for complicated code to look complicated. If your app needs to initialize a lot of complex network dependencies at startup, then maybe your startup routine is going to have a lot of code. No big deal.
Software is complex. We all repeat, and try to follow, the mantra of writing simple code that does one thing. We succeed a lot of the time. But sometimes, we just need to do something f'n complicated. Better to express the complexity in type safe, debuggable code that everyone understands, than to hide it behind some framework.
I think developers should be more accepting of a code base that's 95% clean and 5% messy. "The perfect is the enemy of the good."
Re: Dependency Injection with Go
#26Earlier quoted context omitted.
And why use InitXxx at all, when you can create an initialized, locally-scoped MongoService with a constructor, and pass it to the things that need it?
I was referring to Go's magic func init() Putting that in your files, let's say: db.go func init() => handle global DB's... templates.go func init() => handle HTML templates... settings.go func init() => load some settings... All fired automatically prior to your applications main() entry point WITHOUT needing to pollute main() with initDB(); initTemplates(); initSettings() etc. etc.
> I was referring to Go's magic func init()