4 ms·

If you're doing "dependency injection" by just passing arguments to functions/modules, you're not really doing dependency injection—you're doing "dependencies"

If 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 ago
But that "framework" could be a simple factory function.
com2kid 2y ago
Design 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 ago
No, 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 ago
No, 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.

cryptos 2y ago

But that "framework" could be a simple factory function.

com2kid 2y ago

Design 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 ago

No, 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 ago

No, 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.