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
}
func NewService(databaseConn DatabaseConn) WebService {
return WebService{
databaseConn: databaseConn
}
}
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.
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.
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).
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.