I have already stated several times that I already use DI where I can make use of the facilities which DI provides, but there are places where I choose not to use DI for the simple reason that in those places I will never use the facilities that DI provides, so why should I refactor my code to provide a facility that I will never use?
There is one camp in this discussion whose argument is “you must always use DI even when you are not going to make use of what DI provides” and me all alone in the corner saying “I will only use DI when it is appropriate”.
Yes, you used that exact phrasing actually, but you never explained what facilities you didn’t need that DI would impose. Nor the how in what lead to that decision. That is what we are looking for.
There are two ways of dealing with dependencies - injecting them (using DI, of course) and not injecting them. I choose not to use DI in those places where I cannot make use of the facilities which DI offers.
Incorrect. What you showed me was unusable as it destroyed more than it created.
I am not going to provide code sample that you can run as they would be too large. What I have done is provide in post #102 small snippets from various components - such as a “transaction script” and a “page controller” - which show that by injecting dependencies into the controller I have made those controllers totally reusable.
As for sample code where I don’t use DI then I suggest you look at post #2 which was actually created by you.
I’ve been thinking similarly the whole time too. Especially after reading footnotes about parts of Tony’s code needing to be in his framework so it can support PHP4.
You seem to forget that it was YOU, in post #2, who picked on a sample of MY code and said that it could be “improved” by refactoring to use DI. My argument was, and always has been, that I don’t use DI in that particular piece of code as I have absolutely no need for the facilities which DI provides.
So I have been trying to explain, using samples of MY code, where I DO use DI in contrast to those places where I don’t. The various ways in which DI can be implemented is not something I wish to discuss. In those places where I actually have implemented DI I am not going to change that implementation, and those places where I have chosen not to use DI will forever remain DI-less.
It’s nice to know you’re a fortune teller and know exactly what you may or many not use in the future
How exactly is this a flaw? A
as I pointed out DI is faster and fewer lines of code. By your own words you were arguing that you chose a singleton over di because you wrongly claimed it was less code. As this is not the case, by your own metrics you should be using DI as it will benfit you as it’s less compelx.
Yet again this has devolved through tony’s incessant “MY FRAMEWORK IS THE BIBLE” attitude. He still refused to provide code examples or anything remotely useful. He is essentially trolling at this point and unless he provides some actual substance I vote this thread be locked.
The purpose of DI is to provide the facility to switch one dependency in a consumer to another without having to change any code in the consumer. The dependent is identified outside the consumer and “injected” into it by one means or another. This means that (in theory) the same consumer can be run many times, and each time it can be injected with a different dependent. This produces loosely coupled code where the consumer can be reused with a number of different dependents.
By “inappropriate” use of DI I mean that you provide the facility to inject a different dependent but you never use that facility, you always run that consumer with exactly the same dependent. In my humble opinion the effort taken to refactor a piece of code to provide a facility which you know that you are never going to use is wasted effort and a serious violation of the YAGNI principle. That is why, in those places where I know that I will never change the dependency I choose NOT to use DI.
I DO however use DI to inject Model and View names into my Controllers. This means that both my controllers and views are reusable and I have very low coupling between my Models, Views and Controllers.
I have 3 views and 40 controllers which are currently used with over 300 model classes to provide an application of over 2,500 user transactions. Reusable components are the key, and where I need components to be reusable I will use DI. Where I do not need the components to be reusable I see absolutely no need to use DI.
See this is where you miss the point entirely. We’re not talking about refactoring code to use DI. We’re talking about best-practices and given a clean slate whether you should choose DI or not.
You cannot seem to comprehend the difference between a concept and the knock on effects it has and how implementing it in your existing code would cause you problems. There are quite a few pieces of code I’ve written over the years that if I did it again now I’d do it differently. Will I go back and change them? Unlikely but I can point to flaws in the design and happily discuss how it can be improved. This is not the same as actually going through and refactoring it!
No you did not. You said “I cant do this in my framework because it’s too much work”. That has no bearing on design decisions around choosing DI or an alternative.
