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.
My code IS modular, reusable, understandable and testable. It may not have any automated tests, but automated tests are not a requirement.
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:
In your own words:
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
Just because some people agree on a particular topic does not mean that everyone does. For every opinion you read on the internet you will find many people who express a different opinion.
My code does not meet that definition. My business partner understands my code, and he and his team of developers in India have no trouble is using and extending my code.
I thin that having 9000 lines of code in a single abstract class is a brilliant idea. It means that I have 9000 lines of code which can be shared with a single âextendsâ statement.
Incorrect. I have stated more than once that I actually use DI in my framework where I have the conditions which match the problem which DI was designed to solve. There are places in my framework where I do not have these conditions, so I choose not to use DI.
The argument that TomB and others keep trying to ram down my throat is that I should be using DI for every dependency even when the conditions do not match the design parameters for using DI.
My standpoint is that I see absolutely no reason to implement any design pattern, whether it be DI or something else, unless I have the problem which the pattern was designed to solve.
Yes, and why not?
- 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. âBecause itâs designed for itâ is not a valid answer as itâs self-referencing.
- 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.
Tony, youâve lost. Give up.
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:
In your own words:
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?
See http://www.sitepoint.com/community/t/dependency-injection-breaks-encapsulation/113596/494 for caveats
Post edited by cpradio
I said right at the start of this discussion that there are places where I use DI and places where I do not, and I explained my reasons based on my understanding of the original description of DI as given by Robert C. Martin. You are the one who insisted on having code samples, and when I provided them you immediately jumped on the âletâs insult the quality of Tonyâs codeâ bandwagon.
Post edited by cpradio as there is zero reason to bring that up when it wasnât mentioned in the post you quoted.
Can we take a step back from âchosenâ and keep on with the question I asked in #468
Why wouldnât you use DI? Letâs ignore the other stuff for now and stay on topic: Why wouldnât you use DI on an new project, what would you use in its place and why?
And talk in terms of new projects rather than historical choices as it makes tony defensive about his earlier decisions.
Poppycock. I donât have a different interpretation of what the + operator offers as it is blindingly simple and was taught to me at school. Unless somebody has secretly changed the definition then it means exactly what it has always meant.
The question âwhat is OO?â is not as easy to answer as many people have given many interpretations, and the original concept has been polluted by many add-ons and extensions over the years.
Fair enough, I withdraw my question.
âŚwhich is why weâre asking you to explain the concepts you mean with concrete code examples. I can demonstrate 2+2=4 with rocks or sticks which is why itâs hard to dispute. Similarly, OO concepts such as polymorphism and encapsulation can be demonstrated with concrete code examples.
Perhaps a better analogy is the question âWhat is Mathematics?â, I can demonstrate mathematics to someone by showing them the underlying rules: Counting systems, multiplication, division, logarithms, algebra, âand the original concept has been polluted by many add-ons and extensions over the years.â. The same is true of OOP, itâs just a set of underlying concepts which can be demonstrated with code examples. This is why we ask you to provide code examples to back up the points you make as words (Especially words like âappropriateâ!) are ambiguous.
Where are your unit tests then?
1 Like
I chose to use DI in those circumstances where a dependency could be supplied from a variety of possible candidates.
I chose not to use DI in those circumstances where a dependency could only be supplied from a single source. In order to keep the code simple and in one place, as against the multiple places required by DI, I initially used the ânewâ operator, then I read an article which said that if I needed to access the same class in multiple places it would be more efficient to use a singleton and share the same instance instead of instantiating a fresh instance each time. That seemed to be sound advice, so I created my singleton class and started using it.
Let me state this for the record again - I have never said that a singleton is better than DI. All I have ever said is that in those places where it is appropriate to use DI then I actually do use DI, but in those places where it is not appropriate I choose not to use DI, and the easiest way to obtain an instance which may be shared in other places in the code is to use a singleton.
Post edited by cpradio
Saying that Dependency Injection can be applied is not the same as saying it should be applied.
DI is not used to facilitate the communication between one object and another, it is all about where the dependent object is instantiated. Instantiating an object and invoking a method on that object are entirely different things.
No, I havenât. No, I wonât.
I have never said that a singleton is better than DI.
On a new project I would use DI where I had a dependency which could come from multiple sources. Where a dependency could only come from a single source I would not use DI.
Why is this simple concept so difficult for you to understand?
I was using your own words! DI allows one object to be able to access an instance of another object so that they can communicate, there are other ways of achieving this. Iâm trying to figure out why you choose to use a singleton.
and why?
Why pick a singleton over DI when there is only one source? What is the benefit of doing so? There are plenty of downsides, but I want you to explain the reason you choose to do this.
Iâm not sure why youâre struggling so much to explain your reasoning.
This is going off topic, so I am not going to rise to your bait by providing more code samples which you can ridicule. There are articles on my website which describe my understanding of Encapsulation, Inheritance and Polymorphism, so I suggest you read them. If you disagree with anything which I wrote then I suggest you start a new discussion instead of taking this one down a long and boring path.
The only underlying concepts which form OO are Encapsulation, Inheritance and Polymorphism. If you want to know what these mean then I suggest you read the articles on my website.
Any concepts which came after these three I regard as optional extras which are not required, and as they are not required then I choose not to use them. This again is explained in my article entitled âA minimalist approach to OOPâ.
This is an amusing and very arbitrary approach. Does this apply to other subjects as well? Physics? Where do you draw the line in the sand? Is Newtonâs Law Of Gravitation an âunderlying conceptâ? Is Relativity an âOptional Extraâ?