Let's say Class A depends on Class B. A lot of people have the instincts to have A construct B so that the callers of A don't have to worry about it.

But this makes testing A in isolation difficult. When testing A, you want to mock out B with an instance the test can manipulate.

So we want A to not create B, instead we want B to be "injected" into A. The general strategy of having B passed into A is called dependcy injection.

Dependency injection is one of those technical terms that are made up to describe something that has been done for decades but with a new name because the creators of the new term don't have much experience and/or they want to gain notoriety for creating a new programming technique.

If you've ever written a constructor for a class that has arguments (within the constructor signature) that are used by the instance of the class when instantiated then you have done dependency injection, or put more simply 'passing stuff in' which was eloquently stated in another comment on this thread.

People would have way fewer opinions on it if it was just called "passing stuff in"

It is a pattern where you inject the dependencies of a class into it rather than create the instances of the dependencies within the class. for more info --> https://en.wikipedia.org/wiki/Dependency_injection

it makes the code cleaner and testable.

The idea of DI is that you creat resources indirectly, and don't call the named constructor in your code. You then use interface types to interact with the resource.

This way, your code isn't bound to a specific implementation.

Some DI frameworks even go so far and define all resources in a config file. This way you can switch out the implementation without a recompilation.

No it is a design pattern to structure code. It is also known as the hollywood principle (don't call us, we call you). Meaning that dependencies of a class are provided from the outside, the class itself doesn't know how to create instances of dependencies, just relys on the dependency container (also named inversion of control)...

Going to steal a description I wrote for a blogpost several years ago, when I had recently understood DI for the first time so it was very fresh in my mind:

https://hasura.io/blog/build-fullstack-apps-nestjs-hasura-gr...

Dependency Injection solves the problem of when you want to create something, but THAT something also needs OTHER somethings, and so on.

In this example, think about a car.

A car might have many separate parts it needs:

  class Car {
    constructor(wheels: Wheels) {}
  }

  class Wheels {
    constructor(tires: Tires) {}
  }

  class Tires {
    constructor(rims: Rims, treads: Treads)
  }

  class Rims {
    constructor() {}
  }

  class Treads {
    constructor() {}
  }

We can manually construct a car, like:

  const car = new Car(new Wheels(new Tires(new Rims(), new Treads())))

But this is tedious and fragile, and it makes it hard to be modular.

With dependency injection, it allows you to register a sort of "automatic" system for constructing an instance of "new Foo()", that continues down the chain and fetches each piece.

  class NeedsACar {
    constructor(@Inject private car: Car) {}
  }

And then "class Car" would have an "@Inject" in it's "constructor", and so on down the chain.

When you write tests, you can swap out which instance of the "@Injected" class is provided (the "Dependency") much easier.

Good series about the approach from a functional perspective https://fsharpforfunandprofit.com/posts/dependencies/

You'd do fault injection by injecting dependencies that respond with / throw faults.

I think the poster is referring to Guice or something similar - that there's a framework which selects which instantiated runtime object gets injected as a dependent into another, thereby automatically "figuring out" what object needs to get instantiated first, and then next etc.