4 ms·

> dependency injection The term is unfamiliar to me -- is it related to "fault injection"?

la_fayette 4y ago
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)...
ngc248 4y ago
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 https://en.wikipedia.org/wiki/Dependency_injection it makes the code cleaner and testable.
- everybodyknows 4y ago
  What I find troubling about that page is that it does not qualify up front whether the dependencies are: A. Also depended upon by other, coequal unrelated classes, possibly maintained by others, OR B. Depended upon only by a single class (of higher functionality) Situation A is sometimes called a portability interface; B might be called an internal structuring interface. The difference has crucial implications for social power relationships between the human developers and users involved.
azeemba 4y ago
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.
k__ 4y ago
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.
deleted 4y ago
[deleted]
gavinray 4y ago
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-graphql-api/#dependency-injection-di 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.
- TillE 4y ago
  I know the car is a classic, cliche OOP example, but for any semi-experienced programmer, I feel like it's a really bad choice of analogy which only serves to obscure how you would use a technique like DI in actual real-world code, rather than an artificial toy example.
- jacobsimon 4y ago
  I think you might have it backwards. The first example _is_ dependency injection, too, since you are passing the required instances into the constructor. The non-DI approach would be for the Car class to import and instantiate the Wheels class inside its constructor function.
- sanderjd 4y ago
  The first example is also dependency injection. The rest of what you described is why a dependency injection framework often becomes useful in a system with a large dependency tree. The alternative to dependency injection is for functions to instantiate dependencies internally rather than having them be passed in from the calling context.
okino 4y ago
Good series about the approach from a functional perspective https://fsharpforfunandprofit.com/posts/dependencies/ https://fsharpforfunandprofit.com/posts/dependencies/
rozap 4y ago
People would have way fewer opinions on it if it was just called "passing stuff in"
Simon_O_Rourke 4y ago
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.
dymk 4y ago
You'd do fault injection by injecting dependencies that respond with / throw faults.
itronitron 4y ago
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.
- kagakuninja 4y ago
  I believe the term Dependency Injection was coined by Martin Fowler, as the meaning of the pattern name Inversion of Control is less obvious. I'm going to assume that Martin Fowler has quite a bit of experience, although you might accuse him of wanting to gain notoriety... In any case, DI is not at all a new trendy term. Inversion of Control dates back to the gang of 4 patterns book from the '90s. Yes, constructor parameters are one way to implement DI, but not the only one. I'm ambivalent on the whole pattern movement, but they are a great educational tool for novice programmers, and it is good to have some standard terminology for core patterns. To put it another way, constructor based DI is not simply the use of constructor parameters, it is understanding the OO design principle that side-effecting code should be isolated into objects, rather than just dumping a bunch of DB queries into your functions, like we did back in the stone age.

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)...

ngc248 4y ago

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 https://en.wikipedia.org/wiki/Dependency_injection it makes the code cleaner and testable.

everybodyknows 4y ago
What I find troubling about that page is that it does not qualify up front whether the dependencies are: A. Also depended upon by other, coequal unrelated classes, possibly maintained by others, OR B. Depended upon only by a single class (of higher functionality) Situation A is sometimes called a portability interface; B might be called an internal structuring interface. The difference has crucial implications for social power relationships between the human developers and users involved.

azeemba 4y ago

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.

k__ 4y ago

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.

deleted 4y ago

[deleted]

gavinray 4y ago

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-graphql-api/#dependency-injection-di 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.

TillE 4y ago
I know the car is a classic, cliche OOP example, but for any semi-experienced programmer, I feel like it's a really bad choice of analogy which only serves to obscure how you would use a technique like DI in actual real-world code, rather than an artificial toy example.
jacobsimon 4y ago
I think you might have it backwards. The first example _is_ dependency injection, too, since you are passing the required instances into the constructor. The non-DI approach would be for the Car class to import and instantiate the Wheels class inside its constructor function.
sanderjd 4y ago
The first example is also dependency injection. The rest of what you described is why a dependency injection framework often becomes useful in a system with a large dependency tree. The alternative to dependency injection is for functions to instantiate dependencies internally rather than having them be passed in from the calling context.

okino 4y ago

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

rozap 4y ago

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

Simon_O_Rourke 4y ago

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.

dymk 4y ago

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

itronitron 4y ago

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.

kagakuninja 4y ago
I believe the term Dependency Injection was coined by Martin Fowler, as the meaning of the pattern name Inversion of Control is less obvious. I'm going to assume that Martin Fowler has quite a bit of experience, although you might accuse him of wanting to gain notoriety... In any case, DI is not at all a new trendy term. Inversion of Control dates back to the gang of 4 patterns book from the '90s. Yes, constructor parameters are one way to implement DI, but not the only one. I'm ambivalent on the whole pattern movement, but they are a great educational tool for novice programmers, and it is good to have some standard terminology for core patterns. To put it another way, constructor based DI is not simply the use of constructor parameters, it is understanding the OO design principle that side-effecting code should be isolated into objects, rather than just dumping a bunch of DB queries into your functions, like we did back in the stone age.