Oh dear. We’re back at the factually incorrect “I don’t have the problem X solves” nonsense…
Yes, you do. This is the whole point. You’re saying things like “DI is inappropriate”. You have to prove WHY that statement is true, you also have to prove why your alternativs is “more appropriate”
If others are entitled to their own way then they should not lambast me for not following their way. Why should I respect the opinions of others if they are unwilling to respect mine?
Tony, we would respect you if you:
A) Backed up your claims
B) Listened to what we’re saying
C) Didn’t continually try to change the subject and avoid answering questions.
D) Actually had a valid point
I have described MULTIPLE TIMES exactly what I mean by “appropriate” when it comes to Dependency I injection. I have provided several links to Robert C. Martin’s article at http://www.objectmentor.com/resources/articles/dip.pdf yet you consistently fail to respond to the contents of that article.
Because nowhere does it mention a scenario where DI is “inappropriate”.
I cannot. There are three parts to that question, and I cannot give the same answer to all three parts.
And again an example of tony’s favourite “I refuse to answer direct questions” tactic.
It is possible to have encapsulation without information hiding, therefore information is not a prerequisite of encapsulation.
“Inappropriate” is the opposite of “appropriate”. If you understand which conditions must exist before DI can be considered “appropriate” (and take a look at Robert C. Martin’s “copy” program in http://www.objectmentor.com/resources/articles/dip.pdf for an example of those conditions) then where those conditions do not exist the use of DI is not appropriate.
What point are you trying to make here? You cannot guarantee encapsulation without information hiding. If you don’t want to allow encapsulation to be broken you must use information hiding. It’s a subtle difference but an important one.
If you want to write some code where encapsulation is guaranteed you must use information hiding. If you don’t use information hiding you are essentially saying “Breaking encapsulation is allowed”.
I don’t even know why you’re trying to go down this “I want to argue with factual statements” route again. Do you just like making people explain things to you?
Firstly, that logic is so flawed it’s laughable http://en.wikipedia.org/wiki/Negative_conclusion_from_affirmative_premises
However, even if it weren’t, by that article DI is appropriate when:
By what metric is a singleton “more appropriate” in this regard?
edit: Thirdly, that article does nothing to actually define “appropriateness” it highlights one of the advantages of DI and nothing else. There’s nothing that says “It shouldn’t be used when…” or “In other scenarios, [alterantive] is more beneficial”.
You are lacking any kind of reasoning here. Pointing to an article that highlights one of the many advantages of DI is not the same as explaining when an alternative should be used and why.
It is not difficult to maintain, difficult to test, difficult to reuse, or difficult to understand. I have been using, maintaining and enhancing that abstract class for many years, all without difficulty. My business partner understands it, and his team of programmers in India understand it. The fact that you have difficulty in understanding it shows that you probably have never worked on a large enterprise application which needs all the features which are available in that class.
I disagree, and so do all those people who have sent me private emails supporting my view that DI, when over-used, adds enormous amounts of unnecessary complexity, indirection and obfuscation.
Sometimes the reduction of complexity involves putting complex code inside a single subroutine so that when you want that complexity all you do is call that single subroutine.
I agree that a singleton is not necessary - I could have used the “new” verb. However, by using a singleton I am avoiding the overhead of possibly instantiating the same object multiple times. Using a singleton instance multiple times instead of instantiating a class multiple times is supposed to be “best practice”. I assume you know what “best practice” means?
It is not nonsense, it is basic common sense. That, to you, appears to be an alien concept.
Oh come on Tony you know better than these anecdotes. If this were true you would be able to easily back this up with code examples.
DI solves this exact same problem with less code. Your point is invalid.
I suggest you follow one of my MANY links to Robert C. Martin’s article at http://www.objectmentor.com/resources/articles/dip.pdf which describes the circumstances under which DI can be considered appropriate. Where those circumstances do not exist then DI is not appropriate.
Ok. Agreed, I meant to say loosely coupled, not decoupled.
Scott
Just stop!
Edit: To put this into context I could find an article where someone states that a car is appropriate way to travel from London to Paris… by your ridiculous logic using a car for a journey between Manchester and Glasgow is then “inappropriate”.
I don’t even need to try and understand it. The code quality is such that even with the briefest of glances I can tell it was written by a “dyed-in-the-wool” procedural programmer who doesn’t yet “get” object oriented programming.
Keep trying Tony. Never give up.
I have never claimed that my method of not implementing is better, just that the circumstances do not warrant the use of DI, which makes DI unnecessary.
I listen to what you say, but I do not agree with it. Yet you keep insisting that by not agreeing with it that I am not following “best practice” and therefore must be a bad programmer.
You are the one who keeps changing the subject. I merely try to respond to every argument you throw my way, yet you seem to have great difficulty in understand what I write, even when I try to use words with fewer syllables.
My opinion on DI is held my many others, so my point is perfectly valid.