I do not have to write a long list of needed includes and the start of each script, therefore there is no annoyance. If there is no annoyance there is no problem, and if there is no problem there is no need for a solution.
Ooooh with the obfuscation. Is 400+ not a long list? Just because you chose to put them outside the top of the file (A bad practice even in the days of PHP4 because it makes it impossible to see what dependencies a file has).
Just because you don’t want to use something doesn’t mean it doesn’t solve a very valid problem. As I said before, there are numerous advantages to autoloaders (Development time, developer memory usage, flexibility, fewer lines of code) that. Unless you can demonstrate a situation where autoloaders are measurably inferior to another approach and explain how you’re making that measurement your words are worthless.
[quote=“tony_marston404, post:326, topic:114913”]
That still does not hide the fact that there is no scientific measurement which can tell if one piece of code is better than another. [/quote]
No, you don’t get to move the goalposts today. At that particular moment I wasn’t addressing that claim, I was addressing this one.
So I gave a very simple situation that proved you dead wrong. You’re trying to work from the premise that there is no such thing as better - period. And that’s easily proved wrong. Better can be measured and quantified, if in nothing else than money - better things cost more.
So now you are mixing up SoC with SRP? Come on Tony. Stick to SRP please.
Oh right. You don’t do OOP properly. I forgot. If you did, you’d have that same issue. But, you still do have to make sure your class instantiations have some include or require before the instantiation. Don’t you? So you still have at least a part of the problem autoloaders alleviate.
Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all.
As I said, you don’t understand coupling, stop trying to discuss concepts you clearly have a lack of understanding of. What’s annoying is that you’re arguing that the concepts that you don’t understand are wrong rather than learning what the concepts are.
If you had any idea what coupling was you’d easily be able to understand why inheritance creates tight coupling.
Then what would you think of a popular PHP email library that uses over 120 separate classes, some of which contain just a single method with a single line of code, just to send an email? That, to me, is a perfect example of code which has been degraded from “modular” into “fragmented”.
My framework implements the 3 Tier Architecture which has all the GUI code in the Presentation layer, all the business rules in the Business layer, and all the database code in the Data Access layer. This mirrors EXACTLY what Uncle Bob describes in his article, so who the hell are you to tell me that my interpretation of his article is wrong!
It should also be obvious to anyone with any programming experience that objects in the Business layer absolutely MUST contain code for the following:
(a) Methods which allow it to be called by the layer above it.
(b) Methods which allow it to call the layer below it.
So when you say that the existence of such methods in my abstract class provides a “reason for change” and are therefore a candidate for separation, can you answer one simple question - if I take out the code which allows that class to communicate with other layers, then how am I supposed to communicate with other layers?
The ORIGINAL definition of coupling is defined thus
This is clearly limited to when one module calls another, not when one class inherits from another. The fact that some people have chosen to use the word “coupling” to describe the effects of inheritance is a silly mistake on their part. This is just as silly as the notion that inheritance breaks encapsulation.
If you bothered to read that article which you cited you would have read the following:
This quite clearly states that when examining code using various metrics that the effects of inheritance can be ignored.
I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling.
and
Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all.
and
I understand that inheritance has absolutely nothing to do with coupling. Coupling only comes into play when one module calls another, not when one class inherits from another.
“So they are not related”, “inheritance has absolutely nothing to do with coupling”, “it is quite wrong to say that inheritance automatically produces tight coupling.”
Robert C. Martin (Someone you often reference as an authority) says:
One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class
These opinions are clearly contradictory. Is Robert C. Martin wrong or are You?
You’ll probably try to claim that that somehow the statements don’t contradict each other but that would be a flat out lie. as it’s cut and dry. You can’t even weasel your way out and erroneously claim that it doesn’t apply to abstract classes because he mentions them specifically
And remember this: If you say uncle bob is wrong, anywhere else you’ve cited him as an example to back up your claims becomes invalid because clearly he’s not an authoritative source.
You’re clearly wrong here. Admit it and I’ll let it go.
More importantly, what this does prove is that you don’t know what coupling is which invalidates any argument you have made on the subject of DI, singletons singletons and to a lesser extent TDD as understanding the pros/cons of them relies on a understanding of coupling.
I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling.
and
Neither of those articles put “inheritance” and “coupling” in the same sentence, so they are not related. Your article does not mention inheritance at all.
and
I understand that inheritance has absolutely nothing to do with coupling. Coupling only comes into play when one module calls another, not when one class inherits from another.
“So they are not related”, “inheritance has absolutely nothing to do with coupling”, “it is quite wrong to say that inheritance automatically produces tight coupling.”
Robert C. Martin (Someone you often reference as an authority) says:
One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class
These opinions are clearly contradictory. Is Robert C. Martin wrong or are You?
You’ll probably try to claim that that somehow the statements don’t contradict each other but that would be a flat out lie. as it’s cut and dry. You can’t even weasel your way out and erroneously claim that it doesn’t apply to abstract classes because he mentions them specifically
And remember this: If you say uncle bob is wrong, anywhere else you’ve cited him as an example to back up your claims becomes invalid because clearly he’s not an authoritative source.
You’re clearly wrong here. Admit it and I’ll let it go.
More importantly, what this does prove is that you don’t know what coupling is which invalidates any argument you have made on the subject of DI, singletons singletons and to a lesser extent TDD as understanding the pros/cons of them relies on a understanding of coupling.
No. Coupling only applies when one module calls another, not when one class inherits from another. Just because inheritance combines the code of both the superclass and the subclass, in which case they become “joined” it is wrong to also describe this as “coupling” as that term has a totally different meaning in a different context.
So you’re saying Uncle Bob is wrong? Keep in mind this invalidates any argument you’ve made citing him as an authority.
What do you think $this->method() does when method is defined in the parent class? One “module” is calling another.
edit: And this just goes to prove that you don’t understand coupling. The reason that inheritance creates tight coupling is quite obvious if you understand what coupling is. Go and learn what coupling is in terms of OOP before trying to have a discussion about it.
No. It always comes down to the opinion of a human being, not the opinion of a machine.
In structural engineering it is possible to create machines which test the physical characteristics of building materials to see if they are fit for purpose, but no such machines exist for software engineering.
And we get to see just how ridiculous you are. So the following pieces of code are exactly equal in quality? There is no way to objectively claim one is better than another?
I did not say that there is no such thing as “better”, I simply said that it cannot be measured scientifically. It is all down to a person’s opinion, therefore it is subjective and not objective.
Your reading comprehension level needs some work. If you’d actually read what I wrote I pointed out that you have 400+ require_once lines which would be made redundant. The fact that these aren’t “at the top of a file” is 100% relevant. And as I already said, until you can provide a scenario where an autoloader is inferior in some way to hundreds of require_once lines your argument is invalid.
