Are today's major frameworks capable of enterprise capable applications?

[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.

1 Like

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.

Scott

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”.

That is the most ridiculous statement I have ever read. If you read Robert C. Martin’s article at http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html you will see the following:

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.

Hah! Wow. Backtracking much?

Answer this question: In your own words:

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 :stuck_out_tongue:

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 nothing to do with coupling.

Please answer this question…

In your own words:

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 :stuck_out_tongue:

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.

I do not have ANY scripts in my software which start with 400+ include statements for class files. Not even 40 include statements. Not even 4.

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?

$str =  'a';
$str .= 'b';
$str .=  'c';
$str .=  'd';
$str .=  'e';
$str .=  'f';
$str .=  'g';
echo strrev(strrev(implode(explode('', $str))));
echo 'abcdefg';

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.

Soc (Separation of Concerns) and SRP (Single Responsibility Principle) mean exactly the same thing.

Coupling only exists when one module calls another, not when one class inherits from another.

Could you give a brief description of your understanding of what coupling means?

What exactly do you think happens during $this->method() when method is supplied by a parent/child class?

And please answer the damn question:

Is Uncle Bob wrong or are you?

Tony Marston:

it is quite wrong to say that inheritance automatically produces tight coupling.

Uncle Bob:

One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class

One of you is wrong, which is it?