I’ll create a more in depth response later but as I mentioned in the other thread to understand the problems presented in Tony’s article you first need to take a step back and ask whether those problems need to be solved or if they’re a result of poor design earlier on.
Tony presents some problems and then provides some solutions. However, his initial analysis of the problem at hand is wrong which is why he is having to propose solutions to work around the problems that come from this.
Those statements imply that if you are not using dependency injection (DI) then you are an idiot. I take great exception to that arrogant, condescending attitude. Design patterns are an option, not a requirement. Some OO programmers attempt to go a step further by saying that not only must you use their favourite selection of design patterns, but you must also adhere to their particular method of implementation.
This is a strawman. The point he’s responding to here is making a case for DI and pointing out why it’s better than alternatives. Tony then reframes the original argument about whether A is demonstrably better than B and suggests its about people telling you what to do.
Original Author: DI is better and here’s why
Tony: Stop telling me what I should be doing!
The attitude of these pattern junkies doesn’t work with me. I will decide whether or not I will use a particular design pattern, and I will decide how I implement it. This usually means that I don’t use design patterns at all, and those that I do use are implemented in my own unique way. Because of this I am widely regarded as a maverick, a heretic and an outcast by those who consider themselves to be “proper” OO programmers. If you think you have the stomach for it you can read some of my controversial views in the following articles:
Again, Tony’s gripe here is that people are telling him why DI is better than alternatives and suggesting he should use it because it’s better. Instead of providing any arguments about why DI is inferior to his preferred approach he only argues that he doesn’t want to be told that DI is better. I’m already noticing a theme…
In this example the ‘Person’ class is the consumer and the ‘Address’ class is the dependent. Notice that the dependent object is created/instantiated at the last possible moment just before its service is consumed. This is known as the ‘Just In Time’ (JIT) method of instantiation. An alternative would be the ‘Constructor’ method as shown below:
I covered this in the last thread. Tony is creating a situation where the dependency may not be used then (correctly) identifying that it creates a performance issue. However, rather than trying to solve the original problem of the dependency not being used, he presents a solution to the potential performance issue using singletons (Which are demonstrably bad, again see the last thread for half a dozen or so references).
As an aside, the problem he solves with a singleton:
class Person {
function doStuff () {
....
$objAddress =& singleton::getInstance('address');
$address = $objAddress->getPrimaryAddress($customer_id);
....
} // doStuff
} // end class Person
Could also (and better be solved) using:
class Person {
function doStuff (Address $address) {
....
....
} // doStuff
} // end class Person
This has the advantage that the code is reusable. The $address instance does not have to come from the singleton, it can come from anywhere.
It also prevents me from adding arguments to the constructor of the dependent which are not actually known until I am about to consume its service
This, frankly, makes no sense and highlights a fundamental misunderstanding of DI. With DI you never need to know constructor arguments for dependencies because they are always passed in after they’ve been constructed.
I’ll continue later, but there’s some food for thought. I’ll pick apart his references as well because they’re equally misguided