Dependency Injection Breaks Encapsulation

[TomB]

@tony_marston404

Even on a new project I would not use DI willy-nilly. I would only use it in appropriate circumstances, which is where I had a dependency which could come from a variety of possible sources.

But again: WHY? you keep stating this without a reason.

Did you even read what I wrote? The next paragraph to the one you quoted I said:

Please do this with code examples and a bullet pointed list of reasons for your choice. Words like “Not appropriate”, “not designed for” and others are not a suitable reason, you must demonstrate this with something quantifiable.

And there you go using the word “appropriate” again.

I’m going to paste this post as a response to any subsequent post you make that does not follow the format I described here:

Dependency Injection Breaks Encapsulation

You know what tony, I’ll help you out in order to try to progress this discussion in a meaningful way. As you’re finding it so incredibly difficult to make your own point, I’ll try to steer you towards something that isn’t meangingless by giving you a 3 step template to follow. I’ll restate my argument in the manner I’m asking you to, I think that’s only fair. (I have done this several times already but hopefully another demonstration will help). Note that all code examples are complete, can be…

In your own words:

@tony_marston404

It says quite specifically that Dependency Injection can be applied wherever one class sends a message to another. This implies that I still have a choice as to whether I use DI or not

Given the fact that you can use DI in this scenario and have choice to use it or not, if you choose not to use it and you have a situation where “one class sends a message to another” (You do!) then you must choose to use something else in place of DI to facilitate the communication between the two classes (objects, technically). By making that choice you must have reasoning for picking the chosen approach instead of DI. Explain this reasoning to us please:

Why is a singleton/other approach better than DI when one object needs to communicate with another?

Please answer this in the structure I gave you in #294. If you like you can even use my code to make it easier, but I wanted to give you the opportunity to use your own code,

I’m going to add a few caveats because you keep avoiding the question:

• Saying “DI isn’t designed for…” is both untrue and irrelevant even if it were. This is ad-hoc reasoning and not logically valid http://en.wikipedia.org/wiki/Ad_hoc_hypothesis. To make this statement you must describe, in detail, why something else is better designed or why it is “more appropriate”. “Because it’s designed for it” is not a valid answer as it’s self-referencing. You must provide quantifiable reasons for why something is “inappropriate” saying “Because it is not appropriate” is obviously not an answer!

• Saying “I don’t have the problem DI solves” is also untrue, because, as you already said: “It says quite specifically that Dependency Injection can be applied wherever one class sends a message to another” so if you have more than one class you have the problem DI solves.

• Saying “DI is more code” is a valid point if it were true. But the only way can make this point is with code examples. This is an incredibly easy thing to do if it actually is true

• Referring to Uncle Bob’s article is not a valid answer as it doesn’t state anywhere about when DI should/should not be used

• Debating the points I made in part (3) of my post is not a valid argument, make some arguments in favour of your preferred method instead

• Any answer that doesn’t include code examples is not valid (You can copy/paste my code examples if you like, I just don’t want to coming along and saying “I wouldn’t have done it like that”)

• You must explain how you are measuring “better”, “appropriate”, “practical”, “intended for” or any other ambiguous term you are using to perform any kind of comparison (See section 3 of my post where I did this)

• Changing the subject to encapsulation or anything else is not a valid answer (Again it’s an ad-hoc argument)

• Ad-hoc arguments where you keep moving the goalposts and bringing in different concepts to try to back out of answering the question are not valid ( http://en.wikipedia.org/wiki/Ad_hoc_hypothesis)

• Citing articles that state “Here’s one advantage of DI” and then using that to conclude that all other uses are therefore “bad” somehow is not a valid argument, it’s a Negative conclusion from affirmative premises ( http://en.wikipedia.org/wiki/Negative_conclusion_from_affirmative_premises ) which is logically invalid.

• Pretending to answer this question by using words like “Not intended for”, “inappropriate” or “not practical” has zero weight, if you use terms such as these you must justify why the given approach is “inappropriate” or whatever. This line of reasoning is invalid “It’s not appropriate because it’s not designed to do that. It’s not designed to do that because it’s not practical” Eventually you have to hit the ground and explain using a measurable quanity (Lines of code, execution time, complexity) the terms you are using. This kind of circular reasoning is nonsensical, you must provide short, to the point code examples with reasoning based on a metric we can use to compare different approaches. “Inappropriate” is not quantifiable or tangible in any way ( see http://en.wikipedia.org/wiki/Non-denial_denial ). The only way you can use the line of reasoning is by having two code examples and then explaining why one is more “appropriate” than the other and explaining a tangible way you’re measuring “appropriate”.

What’s most telling is that if you did actually have a valid point this would be incredibly easy for you to answer and demonstrate that your approach is better. The mental gymnastics you’ve been using to avoid the question take so much more effort than it would take to actually answer it just proves you don’t have anything even resembling a valid point. Each time you avoid the question you reinforce the fact that you have nothing to stand on.

Again, I’m going to keep pasting this until you answer the question (So until you get bored of avoiding the question).

For completeness, here’s my post from #286 which is still relevant

@TomB

Why am I asking for code examples?

I’ll take a step back for a second and explain why we need code examples for this discussion. Do you understand why this is important? Because I don’t think you do. You’re on this “Everyone is wrong apart from me” tirade but you cannot back up the claims you make, you’re just trying to justify your poorly thought out code to us and yourself.

You started this discussion, Tony, claiming that DI is somehow inferior to some mythical other approach which you persistently fail to adequately demonstrate. It’s up to you to back up the claim you are making. Words alone are meaningless because they don’t do anything to make your case as we simply do not know exactly what you are referring to. It’s like saying “My car is better than a Ferrari” without either telling us what your car is or explaining in what way you are measuring “better” (Price? MPG? Speed? Looks?)

If we are going to have a discussion about the merits of different solutions to the same problem we need to see both those solutions solving the problem to analyse their efficacy and you must explain how you are measuring the difference. Something you have never managed to do.

In science this is known as a “fair test” by only changing one variable at a time. To analyse the efficacy of one approach over another we must be able to see both methods producing the same result knowing that nothing else is interfering with the test. We can then analyse how well they perform relative to one another. To do this we must remove the concept we are testing from all other external influences and compare it directly to another solution which has also been isolated, otherwise it’s not clear whether it was the approach we are testing that had the effect or something else.

Once again for clarity as this seems to be a sticking point for you. Yes, you do have the problem that DI solves. That problem is locating dependencies. Trying to argue that you do not need to do that is demonstrably wrong. If you have more than one object in the application and one object needs to communicate with another then you need to solve the problem of how one object can see another. DI is a solution to this. Please demonstrate your solution to this problem and explain why it is better than DI.