I spent 500+ posts asking this exact question and got nowhere. All tony can do is say “DI is ‘inappropriate’” but constantly fails to quantify what he means by “appropriateness” or how he’s measuring it. When he finally did quantify it with “number of changes needed” here:
And I showed him that the differences is exactly nil, he ignored my post entirely:
As an aside, in the other thread Tony admitted that Robert C. Martin is not an authoritative reference so the argument he’s making by wrongly applying a single example of Martin’s and saying “any other use is inappropriate” is now an argument he can’t even use, not that it was viable in the first place because it was a negative conclusion from an an affirmative premise ( https://en.wikipedia.org/wiki/Negative_conclusion_from_affirmative_premises )
What tony constantly does is fail to address posts (See the post where I pointed out that his anti-autoloader tirade was stupid and baseless) which he then ignores, changes the subject. Not only does he change the subject but he does it by making statements so objectionable that the original refutation gets lost because he said something so monumentally stupid it can’t be let slide.
It’s an interesting tactic but it’s not a good one. Psychologically Optimism: The Biology of hope sums this up perfectly
There is a tendency for humans to consciously see what they wish to see. They literally have difficulty seeing things with negative connotations while seeing with increasing ease items that are positive. For example, words that evoke anxiety, either because of an individual’s personal history or because of experimental manipulation, require greater illumination before first being perceived.
A famous example of this is the Geologist Kurt Wise who is also a young-earth creationist (Believes the earth is 6000 years old yet studies geology that is millions of years old) who stated:
if all the evidence in the universe turns against creationism, I would be the first to admit it, but I would still be a creationist because that is what the Word of God seems to indicate
This is the exact kind of thing we have with Tony. He’s married to his pre-conceived ideas, evidence be damned. No amount of evidence will convince tony that he’s wrong. He’s made up his mind and nothing will change that, as he consistently demonstrates. The other thread was a perfect example. He was 100% wrong about coupling, he directly contradicted all the known evidence and refuses to acknowledge it because his incorrect definition is immutable in his mind.
As you say, the only reason tony comes here to argue with everyone else is that he’s trying to convince himself he’s right and constantly fails to do so and his arguments become more and more abstract. He never provides proper (academic) references or code examples that demonstrate the point he’s trying to make or if he does provide a reference, he’ll find one sentence he agrees with and take it out of context or use it to make ridiculous inferences. Case in point: Robert C. Martin provides one examples where DI is useful and tony wrongly uses it to extrapolate that “all other uses of DI are inappropriate”
Yes, and Tony keeps saying his understanding of SRP is based in Bob’s definition of SRP, so his 9000 line monster must be OK.
I’d like to tear down the articles Tony listed to prove they prove nothing about Tony’s single argument, that “if there is only one dependency needed, then DI is inappropriate.”
There are two aspects to Dependency Injection. Firstly, an object’s interface should define the services that the object requires as well as those it provides. Secondly, the code that satisfies the requirements of an object by giving it a reference to the services of is collaborators is external to both the object and its collaborators. For this reason, the pattern also used to be called “third-party binding” or “third-party connect”: some third party is responsible for connecting a satisfying a the service requirements of a component (the party of the first part) with those provided by another component (the party of the second part).
He doesn’t back Tony’s argument, but says he doesn’t like poor uses of DI like the DI API in JavaEE, because it “uses reflection to poke dependencies into an object’s private fields, bypassing the constructor, adding a great deal of complexity to client & test code while not providing the benefits that the Dependency Injection pattern should deliver.”
And he goes on to say, he doesn’t like DI frameworks
Personally, I find them more of a hindrance than a help in most situations because they don’t distinguish between “internals” & “peers” (p 50) and so often guide design to a violation of the “composite simpler than the sum of its parts” principle (p 53). I find that I need to clearly understand, and therefore express in code, the dependencies between the objects in the system. Hiding that information away in auto-wiring frameworks or obfuscating it in XML files that, furthermore, cannot be easily refactored just gets in my way when I later need to understand the code and modify it.
Although our discussion isn’t about DI frameworks here, this argument goes along the lines of DI adding complication to the code. Still, the benefits outweigh the disadvantages.
This article doesn’t support Tony at all, as it only presents the arguments of others. In the end, the author takes no sides and asks,
Both loose coupling and encapsulation are valued OO properties, but how shall we handle the balance? Which is the right path?
I generally have to agree with Nate. But I would suggest to use dependency injection sparingly. You don’t have to (or you mustn’t) describe every dependency between types in a central mapping file.
However, Nate and the Author are both talking about using a DI container to manage dependencies, not just using the DI pattern alone. And I would agree, you don’t need to put every dependency in a DI container. That would be overkill and add way too much complication to the application.
This is a very abstract article, which says DI is bad for 3 primary reasons.
“When you use DI as a ’Silver Bullet’ you are losing more then half the abilities of your programming language.”
“Creating Code that is there only to “Enable Change” has a big “YAGNI” written all over it.”
“Developers started to expose private parts of the code to enable testing.”
There are no examples. Just the statements. I don’t agree with 1. or 2. and 3 seems to be the abuse of DI frameworks mentioned by the first article. (You need to read the article to understand the rest of my comment here.) I don’t agree with 1, because the “new” statement isn’t eradicated with DI. Also calling static methods constantly is a bad practice anyway. I don’t agree with 2, especially for larger applications, because the small effort to use DI will greatly outweigh the inflexibility you will face should you actually have to change the code without DI. The sealed types of part 1 is also a part of the third reason, as I see it and again is abuse of DI frameworks (containers), not DI alone.
This article doesn’t even come close to supporting Tony. And actually, it counters Tony’s arguments.
At the cost of a single line of code, you get benefits well beyond the already mentioned ability to transform the class into an abstract base class:
…
- You can implement the Dependency Injection pattern, which facilitates
unit testing with mock objects.
This guy takes DI and uses its possible negative side effects, the complication of code, to actually hack on OOP itself. It doesn’t support Tony’s argument directly or with any kind of substance.
In the article “Dependency Injection Makes Code Unintelligible” the author, as others do, talks about DI frameworks being bad, when abused. It makes code less understandable. I don’t think anyone disagrees with that. The author, however, doesn’t talk specifically about DI itself as a beneficial or detrimental coding pattern.
This is one of the better articles and doesn’t support Tony at all. In fact, the author starts with “I love dependency injection”. What the author does here is not only speak about DI frameworks, but actually how to make them better.
So, after taking the time to read all of those articles, I think we need to make two clear distinctions, when talking about DI or DI containers.
DI, as a pattern alone, is quite beneficial and has few disadvantages. It is hard to overuse it or use it inappropriately.
DI frameworks or containers, take the beauty of DI and increases its subtle power beyond all the “boarders” of the application. As such, it can be abused, overused and used quite inappropriately.
Clearly, the two points are talking about two completely different things.
Nicely done. It’s worth mentioning as well that whether or not DI is “appropriate”, however you’re measuring that, to make a valid point tony needs to provide an alternative to DI (E.g. singletons) and explain why it is more appropriate than DI explaining the metric he is using (Less code? Faster execution? etc) Tony’s argument falls down here and he just says nonsense like “DI isn’t designed for cases where there is only one dependency” which is a non-answer and circular reasoning: DI isn’t appropriate because it isn’t designed for it… it doesn’t answer the question because it doesn’t provide an alternative and explain why that alternative is “better designed”. Tony’s argument rests on abstracting the word “Appropriate” to “not designed for” or other variations of the same weasel words.
I believe that Tony’s work on his existing singleton design has him faced with a position of defending it, even against insurmountable amounts of evidence. He had a strong investment of time and money in it, and pride plays not a little factor in this too.
It is also why people that believe the moon landing was a hoax, are not likely to change their minds even when conclusive proof and evidence is given.
There’s a psychological aspect going on here that is tricky to understand, and even harder to do something about.
You will never find the real truth among people that are insecure or have egos to protect. Truth over time becomes either guarded or twisted as their perspective changes; it changes with the seasons of their shame, love, hope or pride.”
I missed this post in the fog of everyone else proving you wrong again but it needs responding to. What is the difference between:
new Person(new Apple)
and
$person->eat(new Apple);
If the first “breaks encapsulation” because “By injecting a dependency you are exposing the implementation by telling the object how to carry out the service which you are requesting” then so does the second.
What you seem to miss, and Jeff already pointed out eloquently is that you’re not exposing the implementation, you’re exposing the argument types and nothing else. In what way does new Person(new Address) expose how the person uses the address object? Similarly $person->eat(new Apple) doesn’t expose how the person eats the apple only that they can eat something.
I’ve found the following article to be quite insightful when it comes to encapsulation vs dependency injection, which breaks the two down in to the following:
Some people don’t like dependency injection because you are giving control over to the user of the class, and others don’t like encapsulation due to it being inflexible to change for future requirements.
I like bringing things back to Uncle Bob though (Robert C Martin), for he seems to have a good head on these matters. Dependency Injection by Uncle Bob Martin - where he says you shouldn’t always do it.
That’s not what he says at all. If you watch the video he says you should inject a factory into various components and then from there “inject using normal means”. He specifically says “Because I don’t want the business rules to know about the dependency injection framework”. He’s not saying dependency injection shouldn’t be used, only that the business rules should not be dependant on the container, which is completely logical (And incidentally, one of the reasons why @Inject is a horrible idea)