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

[tony_marston404]

@TomB

Stop just stop. We’ve already been through this. You can use an autoloader, you chose not to, you can use DI, you chose not to.

Your use of the word can instead of should implies that I am allowed to make my own choices then? And that one choice is not necessarily “bad” while the other is automatically “good”?

@TomB

You made an alternative choice, the merits of the different approaches can be weighed up and analysed, and you always seem to fall on the side of the measurably worse choice.

Who says that my choices are the worst? They still work, like they have done for many years, so how come they are automatically bad just because there is now a different way of doing exactly the same thing?

[quote=“TomB, post:318, topic:114913”]

tony_marston404:
This is why with just 40 controllers I can generate an application with over 2,500 user transactions

The fact you have 2,500 of anything speaks volumes. If you need 2,500 variants of something, you’ve got repeated code there.[/quote]
Then you have obviously not worked on a large enterprise application. Each one of those 2,500 user transactions - which you might now as “use cases” - does something different to a different Model class. I don’t have any repeated code as anything which could be repeated has been placed into a reusable module.

@TomB

100% Wrong. There are lots of ways to measure “better”: Performance, lines of code, readability, flexibility, portability, etc.

Lines of code would be a stupid way to measure “better”. Readability cannot be measured scientifically, it is a matter of personal perception. Flexibility cannot be measured scientifically, you need to apply an actual change to see how easily that change can be implemented. As for portability, my application can run on any platform on which PHP can be run, and it can be run with a choice of databases - MySQL, PostgreSQL, Oracle or SQL Server.

@TomB

You perpetually miss an important point: Best practices evolve out of tried/tested solutions.

And you keep missing an important point. There is no document entitled “Best Practices” which exists in a single place, there are simply thousands of different opinions in thousands of different places. Even if there were a single document it would never be universally accepted by all programmers. Each programmer has his/her own different opinion on what is best for them. I most definitely AM following best practice, but it is not the same version as yours.

@TomB

tony_marston404:
The title of this discussion is “Are today’s frameworks capable of enterprise capable applications?” to which I have given my honest answer.

More irrelevant anecdotes… None of this matters one iota to the topic at hand.

How so? They directly respond to the question around which this discussion was originally based. You are the one who keeps changing the discussion into attacks on either my methodology or me personally.

@TomB

Then you have had a chance to use modern techniques and actively chosen to avoid them. This is negligence as they would have provided measurable benefits (Faster development time, less buggy end result)

I chose to avoid those techniques which I saw had no benefit. This is not negligence, it is prudence. As for faster development time and less buggy end result, my development times are faster than yours, and neither my framework nor my enterprise application have any outstanding bugs.

@TomB

tony_marston404:
I repeat - inheritance has absolutely nothing to do with coupling, therefore it is quite wrong to say that inheritance automatically produces tight coupling.

And you again prove you don’t know what coupling is.

Yes I do. My understanding comes from such articles as http://en.wikipedia.org/wiki/Coupling_(computer_programming) Can you point to any authoritative article which says that inheritance produces tight coupling?

@TomB

tony_marston404:
You did not prove that I was wrong, you simply proved that you do not understand the problem for which DI is the solution, even after I pointed you to Robert C. Martin’s original article which clearly shows that DI has benefits only where a dependency can be provided from one of several sources.

I’m not getting into this again, I repeatedly proved your incompetence in the other thread, go read that.

No, you simply proved that you cannot read, and that you dislike any opinion which is different from your own.

[s_molinari]

@tony_marston404

One approach is to have a single class with 120 methods while a different approach would be to have 120 classes with a single method each. Which in your opinion would be the most readable?

Both are wrong and the discussion isn’t about readability. It is about SRP.

@tony_marston404

So you would agree then that an over-enthusiastic interpretation of the Single Responsibility Principle can lead to code which is too fragmented?

Sure. However, it is a lot rarer to find too much fragmentation. I personally have never ran across it. I have, however, seen a good number of classes doing too much.

@tony_marston404

It fits my interpretation of SRP.

And your interpretation doesn’t follow the same interpretation made by the best minds of programming, like Uncle Bob Martin.

@tony_marston404

That is all the separation that I deem necessary.

And you can deem what is necessary all you want Tony. Just don’t declare it better or correct, because it simply isn’t.

@tony_marston404

, and my abstract class contains all the methods that either a Controller or a View can use on a Model, or where the Model calls a DAO

Look at that single sentence Tony. There are already three reasons to change your class.

@tony_marston404

So why do you and your cohorts keep telling me that I should replace all my include statements with an autoloader?

We don’t. You interpret what we are saying incorrectly. It is a bad habit you should get rid of.

@tony_marston404

I do not have the problem that autoloaders were designed to solve, so I don’t need one as a solution.

No, you most definitely have the problem autoloaders were designed to solve, but are defiant to use it as a solution.

@tony_marston404

It may be an improvement,

Hey! Finally, we almost agree!

@tony_marston404

it is one that I don’t need, which is why I will not change my entire code base to use namespaces.

Nobody cares, about what you need or not. And nobody is asking you to change your entire code base either. When will you start to understand that?

@tony_marston404

Whether a new feature is actually an improvement or not depends on your point of view. But just because something is new does not mean that I should rush out and implement it immediately. If I have last year’s model of smart phone, but this year’s model is “new and improved”, why should I spend money on this year’s model if I have no need of the new features. Like most people I wait until I have paid for my current model until I go out and buy a new one.

So, let’s take this phone analogy a bit further. It is fine, if you don’t go and spend money on the newest phone.

It is NOT ok to start telling everyone else that the new phone doesn’t have new features and that even the improvements are “evil” and the people who decide to spend money on the new phone and use the new improvements are “mindless monkeys”.

Think about it. If you would stand in front of an Apple store holding signs up saying the new improvements are evil and the people who buy new phones are idiots for doing so, what would happen? At worst, you’d get put up in a mental ward, at best, the passersby would think you are simply barmy.

Scott

[tony_marston404]

@TomB

The problem here is that you clearly haven’t learnt from your mistakes.

Cobblers. I have learned to spot mistakes and never to repeat them.

@TomB

When you have everyone here and elsewhere telling you you’re going down the wrong path, there’s something in it.

It is not the wrong path, just a different path. Just because a thousand people keep repeating the same lie does not turn it into the truth.

@TomB

TomB:
You cannot see that? How?? Default_Table is hardcoded, Your class will always extend the default table class

Exactly. Every one of my Model classes inherits from the same abstract class. What is wrong with that? Some people actually say that classes should only be allowed to inherit from abstract classes, which is exactly what I have implemented.

@TomB

Again, go and learn about coupling as it’s clear you don’t understand it.

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.

[TomB]

@tony_marston404

Your use of the word can instead of should implies that I am allowed to make my own choices then? And that one choice is not necessarily “bad” while the other is automatically “good”?

I’ll just quote myself…

@TomB

Not that this matters. You can either use an autoloader or use require_once, an autoloader has measurable advantages over not using one (Development time, repeated code, developer needs to remember less). Whether you choose to use one or not is again, anecdotal and irrelevant. Unless you can demonstrate a situation where an autoloader is inferior to another approach, your post is meaningless.

@tony_marston404

Who says that my choices are the worst? They still work, like they have done for many years, so how come they are automatically bad just because there is now a different way of doing exactly the same thing?

Given two approaches we can measure the differences and assess which is better, has fewest drawbacks/most advantages.

@tony_marston404

Flexibility cannot be measured scientifically

Of course it can, most easily by looking at coupling. Tight coupling is by definition less flexible than loose coupling.

@tony_marston404

And you keep missing an important point. There is no document entitled “Best Practices” which exists in a single place, there are simply thousands of different opinions in thousands of different places. Even if there were a single document it would never be universally accepted by all programmers. Each programmer has his/her own different opinion on what is best for them. I most definitely AM following best practice, but it is not the same version as yours.

And yet you constantly refuse to identify what these best practices are. When you attempt to you cite SRP, which you are clearly not following no matter how many times you claim to be.

@tony_marston404

How so? They directly respond to the question around which this discussion was originally based. You are the one who keeps changing the discussion into attacks on either my methodology or me personally.

You keep bringing your code into it, I am simply scrutinizing it. Don’t bring your code/methodologies up and it won’t get critiqued.

@tony_marston404

Can you point to any authoritative article which says that inheritance produces tight coupling?

Wikipedia is not authoritative. Here’s an academic paper:

oocross.pdf

. Inheritance introduces significant tight coupling between superclasses and their
subclasses.

@tony_marston404

No, you simply proved that you cannot read, and that you dislike any opinion which is different from your own.

Go and read the other thread, I posted some code examples (You still did not) to back up my point. You never said what metric you’re using to measure “better”, provide code samples or even expand on your point when asked.

[TomB]

@tony_marston404

Exactly. Every one of my Model classes inherits from the same abstract class. What is wrong with that? Some people actually say that classes should only be allowed to inherit from abstract classes, which is exactly what I have implemented.

As I said, it’s tightly coupled. Until you understand what coupling is, you’ll never be able to understand why singletons are bad, why TDD is good and why DI is beneficial. These are all related and this is a major sticking point for you.

[TomB]

Oh and you’ll like this Tony. Your favourite author Robert C. Martin on inheritance and coupling:

http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

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

For reference, this is what you said

@tony_marston404

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.

Will you admit you’re wrong?

[tony_marston404]

@s_molinari

tony_marston404:
It fits my interpretation of SRP.

And your interpretation doesn’t follow the same interpretation made by the best minds of programming, like Uncle Bob Martin.

I disagree. In Uncle Bob’s article at http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html is says the following

How do you separate concerns? You separate behaviors that change at different times for different reasons. Things that change together you keep together. Things that change apart you keep apart.

GUIs change at a very different rate, and for very different reasons, than business rules. Database schemas change for very different reasons, and at very different rates than business rules. Keeping these concerns (GUI, business rules, database) separate is good design.

That is PRECISELY why I have my GUI, business rules and database access in separate modules.

@s_molinari

tony_marston404:
I do not have the problem that autoloaders were designed to solve, so I don’t need one as a solution.

No, you most definitely have the problem autoloaders were designed to solve, but are defiant to use it as a solution.

You still haven’t learned to read, have you? If you too the time to read http://php.net/manual/en/language.oop5.autoload.php you would see the following in the very first paragraph:

Many developers writing object-oriented applications create one PHP source file per class definition. One of the biggest annoyances is having to write a long list of needed includes at the beginning of each script (one for each class).

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.

[fretburner]

@tony_marston404

Lines of code would be a stupid way to measure “better”. Readability cannot be measured scientifically, it is a matter of personal perception. Flexibility cannot be measured scientifically, you need to apply an actual change to see how easily that change can be implemented.

Do you believe there are any objective measures or standards by which someone could compare the quality of one piece of code against another?

[TomB]

@tony_marston404

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.

[Michael_Morris]

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

@tony_marston404

“Better” is not something which can be measured scientifically, it is simply a subjective observation.

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.

[s_molinari]

@tony_marston404

I disagree. In Uncle Bob’s article at http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html is says the following

So now you are mixing up SoC with SRP? Come on Tony. Stick to SRP please.

@tony_marston404

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.

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

[tony_marston404]

@TomB

As you don’t understand coupling. Go and read the section on it here:

https://nikic.github.io/2011/12/27/Dont-be-STUPID-GRASP-SOLID.html

Or my own explanation here:

https://r.je/slutty-software-tight-and-loose-coupling.html

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.

[TomB]

@tony_marston404

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.

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

Oh and you’ll like this Tony. Your favourite author Robert C. Martin on inheritance and coupling: http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf One of the problems with implementing an abstract class with inheritance is that the derived class is so tightly coupled to the base class. For reference, this is what you said Will you admit you’re wrong?

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.

[tony_marston404]

@s_molinari

tony_marston404:
So you would agree then that an over-enthusiastic interpretation of the Single Responsibility Principle can lead to code which is too fragmented?

Sure. However, it is a lot rarer to find too much fragmentation. I personally have never ran across it

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

@s_molinari

tony_marston404:
my abstract class contains all the methods that either a Controller or a View can use on a Model, or where the Model calls a DAO

Look at that single sentence Tony. There are already three reasons to change your class.

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:

How do you separate concerns? You separate behaviors that change at different times for different reasons. Things that change together you keep together. Things that change apart you keep apart.

GUIs change at a very different rate, and for very different reasons, than business rules. Database schemas change for very different reasons, and at very different rates than business rules. Keeping these concerns separate is good design.

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?

[tony_marston404]

@TomB

tony_marston404:
Can you point to any authoritative article which says that inheritance produces tight coupling?

Wikipedia is not authoritative. Here’s an academic paper:

The ORIGINAL definition of coupling is defined thus

In software engineering, coupling is the manner and degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.

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:

Classes (objects) are coupled three ways:

1. When a message is passed between objects, the objects are said to be coupled.
2. Classes are coupled when methods declared in one class use methods or attributes of the other classes.
3. Inheritance introduces significant tight coupling between superclasses and their subclasses.

Since good object-oriented design requires a balance between coupling and inheritance, coupling measures focus on non-inheritance coupling.

This quite clearly states that when examining code using various metrics that the effects of inheritance can be ignored.

[TomB]

@tony_marston404

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.

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

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.

[tony_marston404]

@TomB

tony_marston404:
Exactly. Every one of my Model classes inherits from the same abstract class. What is wrong with that? Some people actually say that classes should only be allowed to inherit from abstract classes, which is exactly what I have implemented.

As I said, it’s tightly coupled

I repeat, inheritance has nothing to do with coupling.

[TomB]

@tony_marston404

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

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.

[tony_marston404]

@TomB

Will you admit you’re wrong?

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.

[TomB]

@tony_marston404

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.