[KronisLV]

> my_object = MyObject(a,b,c)

> If a, b and c are MyObject's "dependencies", that's dependency injection.

In practice, though, at least coming from a Java/.NET background, DI would be understood as using something like a decorator/annotation/some registration mechanism to let the framework handle giving you a valid instance of the class that you're after, rather than straight up using the constructor whilst filling out the parameters manually.

While your example is technically true, it wouldn't be the answer that anyone in a programming interview (at least for those languages) might expect you to provide as an example.

That said, adopting the composition root approach in a Java project (or using a god-object for all of the services) was oddly liberating and felt way more simple than mucking about with appeasing Spring's @Autowired annotation and its finnicky nature.

[necovek]

Like most fields of endeavour, programming has gotten infested with "smart" speak and too much terminology (let's talk the rest of Design Patterns next :D), and this same terminology changes even between different teams and not just different companies or technologies. Basically, people have a tendency to want to name pretty simple things names just so they are something special, even if they need to re-explain it every single time (there is no value in such a name, imho).

The fact that most of that terminology is misunderstood simply supports that claim above. The fact that interviews are also generally silly is besides the point too. :)

Still, none of that should be a benchmark for what something is. Dependency injection is simply about injecting a dependency instead of using it as a side-effect. You can achieve that in many ways, and the simplest is just to pass it in.