re: Explain dependency injection like I'm five VIEW POST


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.

code of conduct - report abuse