Timeline for Why should I use dependency injection?
Current License: CC BY-SA 4.0
18 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 16, 2018 at 2:53 | comment | added | rurouniwallace | "As a customer, when you hire a mechanic to do something to your car, do you expect that mechanic to build a car from scratch only to then work with it? No, you give the mechanic the car you want them to work on." this is the single best analogy I've ever heard for dependency injection. | |
| Nov 15, 2018 at 12:17 | comment | added | Flater | @gbjbaanb: At no point does my answer even remotely delve into polymorphism. There is no inheritance, interface implementation, or anything resembling the up/downcasting of types. You are completely misreading the answer. | |
| Nov 15, 2018 at 11:41 | comment | added | gbjbaanb | Your analogy is flawed and confusing to anyone trying to understand what DI is. You focus on polymorphism when DI is about coupling. Anything that needs 3 long comments to justify it, says its bad. | |
| Nov 15, 2018 at 7:02 | comment | added | Flater | @gbjbaanb: In other words: you're right that my answer's example suggests that any spoiler can be attached to any car using any screwdriver. And while that may not be the case in reality, it is the simple example I chose to use. The real world validity of every combination of car/spoiler/screwdriver being possible is not really relevant to the question we're answering here. | |
| Nov 15, 2018 at 6:59 | comment | added | Flater |
@gbjbaanb: What you say isn't wrong, but it's adding previously unmentioned detail to what is a simplified example, and you're focusing on something else entirely. My answer focuses on the responsibility (and thus inherent dependency) of object creation vs receiving an existing object (and not needing to bother creating it, knowing where it came from, who made it or if it's a derived version or what the class is expecting). You're focusing on whether Car is too broad as a type for the input, which is indeed an interesting consideration but simply not what this answer focuses on.
|
|
| Nov 14, 2018 at 18:05 | comment | added | IMSoP |
@gbjbaanb I think the analogy can be extended naturally to the EV example: the mechanic specifies constraints on the cars he accepts; in an OO language, that would be represented as the interface the dependency must implement. In the simple example, the constraint is "any car", but in reality it would be "any car with an internal combustion engine", or some more specific description; an EV car wouldn't meet that constraint, so wouldn't be accepted. In OO terms, NissanLeaf would be a new class that implemented an EVCar interface, but didn't implement the InternalCombustionCar interface.
|
|
| Nov 14, 2018 at 15:57 | comment | added | gbjbaanb | Your mechanic analogy is poor even as an analogy. If I have a mechanic trained how to fix cars, he can fix most varieties but if I come to him with a EV instead, he's likely to have no clue what to do with it. DI does not fix the polymorphic problem, all it does is help with coupling - ie how to get the car and mechanic together. A better analogy is a mechanic working for a dealer who only fixed 1 brand of car going independent and fixing other brands of car. | |
| Nov 14, 2018 at 7:20 | comment | added | Flater | @jpmc26: I've removed the code snippet due to confusion but the analogy itself remains correct in my opinion. | |
| Nov 14, 2018 at 7:19 | history | edited | Flater | CC BY-SA 4.0 |
deleted 191 characters in body
|
| Nov 13, 2018 at 16:50 | comment | added | jpmc26 | @Flater The problem with the example is that you would almost certainly not model any problem in code this way. It is thus unnatural, forced, and adds more questions than answers. That makes it more likely to mislead and confuse than to demonstrate. | |
| Nov 13, 2018 at 14:44 | comment | added | Flater | @Ewan: How so, specifically? Imo it fits as an analogy - don't create things when their creation isn't part of your job. | |
| Nov 13, 2018 at 13:29 | comment | added | David Arno | @Flater, part of the problem is no one really seems to agree on what the difference between dependency injection, dependency inversion and inversion of control are. One thing is for certain though, a "container" most certainly isn't needed to inject a dependency into a method or constructor. Pure (or poor man's) DI specifically describes manual dependency injection. It's the only dependency injection I personally use as I dislike the "magic" associated with containers. | |
| Nov 13, 2018 at 13:16 | comment | added | Ewan | I think the whole car thing is a bit belaboured and confusing | |
| Nov 13, 2018 at 13:00 | history | edited | Flater | CC BY-SA 4.0 |
deleted 174 characters in body
|
| Nov 13, 2018 at 12:49 | comment | added | Flater | @DavidArno As I understand it, injection is the automated filling of method/constructor parameters as opposed to manually passing them. For the locator, does the locator itself then not become a dependency? It sounds like it's shifting the problem. | |
| Nov 13, 2018 at 12:21 | comment | added | David Arno | If you removed your comment, "As a minor comment, your question focuses on dependency inversion, not dependency injection. Injection is one way to do inversion, but it's not the only way.", this would be an excellent answer. Dependency inversion can be achieved via either injection or locator/globals. The question's examples relate to injection. So the question is about dependency injection (as well as dependency inversion). | |
| Nov 13, 2018 at 9:56 | history | edited | Flater | CC BY-SA 4.0 |
deleted 1 character in body
|
| Nov 13, 2018 at 9:51 | history | answered | Flater | CC BY-SA 4.0 |