5 ms·
> Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work. > I spent quite a lot of time using wire for DI in go only to reall
by _w1tm 2y ago
> Also DI, which is arguably not necessary at all in Go given how elegantly interfaces work.
> I spent quite a lot of time using wire for DI in go only to really study the code it was generating and realizing it truly is code I would normally just write myself.
DI is the idea that you should create your dependencies outside of the module / class / function that uses it and pass it in. This makes it easy to swap implementations.
DI does not require any framework and I would argue you can’t write modular code without it. Most likely you are doing DI even in your manually written code.
- RussianCow 2y agoIf you're doing "dependency injection" by just passing arguments to functions/modules, you're not really doing dependency injection—you're doing "dependencies" without the "injection" part. I'm not saying that DI necessitates a ton of magic, but you need at least a small framework for specifying dependencies and injecting them into your modules dynamically.
- cryptos 2y agoBut that "framework" could be a simple factory function.
- com2kid 2y agoDesign patterns are independent of the implementation technology. OO and virtual functions can be implemented in C by looking up function pointers in a table. Reference counting can be done by manually incrementing and decrementing references. At the end of the day everything is compiled to assembly and the CPU doesn't care what ideology was in the programmer's head, except however much a given paradigm abstracts too far away from the underlying machine.
- lucumo 2y agoNo, that's wrong. DI requires that the deps come from outside, not that it's dynamically created. The opposite is that dependencies are created inside the unit. DI is about which part of the code owns the dependency. With DI it's some parent component, without DI it's the component itself. DI with magic can simplify the management of component lifecycles, but it's entirely possible to do it without.
- gf000 2y agoNo, you can pass (inject) the necessary dependencies to the constructor of an object at creation time, and then simply use that object instance everywhere. The only thing frameworks do is "solve" the dependency graph and instantiate stuff in the correct order. This is also the most common/preferred way Spring et alia implements their "framework-aided" DI, so that you can write unit tests easily without bootstrapping a Spring context (and it is just well-designed vanilla Java code).
- simiones 2y ago"Injection" in "dependency injection" simply refers to getting your dependencies from outside instead of building them yourself. Let's take the case of an object which represents a simple CRUD web service that needs to talk to a database to get some data. Here is what it looks like without dependency injection: func NewService(databaseHostname, databaseLoginSecret string) (WebService, error) { databaseConn, err := databse.NewConn(databaseHostname, databaseLoginSecret) if err != nil { return WebService{}, fmt.Errorf("Failed to create database conn for WebService: %w", err) } return WebService{ databaseConn: databaseConn }, nil } And here is what it looks like with dependncy injection: func NewService(databaseConn DatabaseConn) WebService { return WebService{ databaseConn: databaseConn } } This is the only concept: don't build your own dependencies, get them from outside. Ideally then there is a place in your application, possibly in `main()`, where all of the base services are initialized, in the required order, and references are passed between them as needed. This can include "factory" style objects if some of these need to be initialized on-demand.