Traditional: going to a party, bring your own drinks.
Inversion of control: going to a party, there is an ice chest full of drinks, and there's a guy handing out the drinks from the ice chest. You only get to drink what's been handed to you.
Dependency injection: going to a party, and there's an open bar, the bartender makes your drinks, and servers brings you your drinks. You don't know what you're drinking, but it tastes good.
Dependency injection is a fancy kind of Inversion of Control, but also has a bartender & servers.
Traditional: Picking what to wear when you get up in the morning.
Dependency Injection: Asking a pants, t-shirt and an hat from a stylist, and he makes sure you look lit AF.
This is gold 😂
now I need dependency injection in my life
"Dependency Injection" is a fancy way of saying that you have to ask someone else, like Mummy or Daddy, to give you anything you want to play with. You can't make the toy yourself, you need Mummy and Daddy to get it for you.
Sometimes, you don't know what toy you are going to get, like on your birthday, but all you need to know is that it will be a fun toy you can play with when you open the present.
And this really helps mummy and daddy because you're not very good at cleaning or maintaining or watching over your toys. They'd rather not bother you with that stuff. Your "job" is to make use of the toys and have fun, not to build and take care of them.
If parents made their kids learn to create and clean their own toys, it might be possible to teach everyone to do this, but it would be easy to mess up, and they'd have a hard time being sure they got it right.
I just spent over an hour trying to create an example. Decided it's the wrong approach even if it's not the #explainlikeimfive version. The hardest part is the why.
Say you have a car repair shop. The non DI way would be to require your mechanics to bring their own tools.
The DI way would be to provide tools for your mechanics.
The DI way makes life easier on the mechanics, no need to worry about buying tools and bringing them to the shop.
For the owner, it's a little more involved. He needs to have knowledge of what tools a mechanic requires. And he needs to buy them. But it can be a good tradeoff. He might be able to get bulk deals. He gets to decide what quality the tools should be.
Okay this is better than what I had. Head still spinning :)
Sometimes, the mechanics have really special needs and don't trust their boss to supply them with the best tool, so they bring their own instead. But this makes life harder for the owner, because if he wants to start servicing forklifts in addition to cars, he can't supply you with a new, all-in-one tool.
For DI to work, you have to trust that the best option for any given scenario can and will be supplied to you.
c = sys.stdin.read(1)
if not c:
raise Exception('unexpected EOF')
In the code above I'm implicitly depending on standard input. So standard input is a dependency of the function. Among other things it makes that code harder to test.
The code is okay but one way in which it can be improved is by making the dependency on standard input explicit. Here's how:
c = input.read(1)
if not c:
raise Exception('unexpected EOF')
Pass the dependency as an argument which makes it explicit. The function now takes a file like object which I defaulted to standard input since that would be the typical use case.
What have we gained? The code is much easier to test and understand because you know what depends on what. It's dependencies are explicit.
Passing your dependencies via arguments to functions is one way to "inject your dependencies", hence the term "dependency injection".
If you want to see how it helps with testing in a real project then you can read these examples from my Python Whitespace interpreter project:
Traditional: You get happy to see the pink ice cream van because you know you'll buy ice cream.
DI: The pink van is not here today but you still happy as there is another blue van that sells ice cream.
No matter which van you see, you'll still happy to get what you're after... ice cream.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.