Would you agree this is the definition of a PHP framework?

You may not think so, but both my previous and current business partners, and the customers who use it on a day-to-day basis to conduct their business, would disagree with your opinion. THEIR opinion is much more valuable to me than yours, so you might as well keep your opinion to yourself.

Each of the 2,500+ transactions in my application has its own transaction script, as described in http://www.tonymarston.net/php-mysql/infrastructure.html#component.script, which looks like the following:

$table_id = "person";                      // identify the Model
$screen   = 'person.detail.screen.inc';    // identify the View
require 'std.enquire1.inc';                // activate the Controller

Each script therefore specifies a unique combination of Model, View and Controller, therefore there is no violation of DRY.

Then stop coming here and trying to convince people your framework is “good”.

You do realise it would take longer to navigate into a GUI, move between form fields and type into text boxes than it would to just type out the code in the first place?

I have already provided links to such articles in post #225, so here they are AGAIN

For at least the fifth time: There is nothing in those articles that says SoC and SRP are the same thing.

This one doesn’t even mention SRP

This one mentions them both but doesn’t say they’re the same


This one by Robert C. Marin actually states they are different:

Two years later, Edsger Dijkstra wrote another classic paper entitled On the role of scientific thought. in which he introduced the term: The Separation of Concerns.
The 1970s and 1980s were a fertile time for principles of software architecture. Structured Programming and Design were all the rage. During that time the notions of Coupling and Cohesion were introduced by Larry Constantine, and amplified by Tom DeMarco, Meilir Page-Jones and many others.
In the late 1990s I tried to consolidate these notions into a principle, which I called: The Single Responsibility Principle. (I have this vague feeling that I stole the name of this principle from Bertrand Meyer, but I have not been able to confirm that.)
The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change. This sounds good, and seems to align with Parnas’ formulation. However it begs the question: What defines a reason to change?

He specifically states he combined several already defined concepts and called it SRP. Saying SoC is the same as SRP is like saying “A cake and butter are the same thing because the cake contains butter”.

It’s impossible to have SRP without SoC but it’s not impossible to have SoC without SRP. One is more refined than the other.

What!!! But the end result is the same… a web page/application that accepts user input and renders output. How can they be different when the end result is the same!!! mind blown

1 Like

In both articles Uncle Bob states that separating out the logic for the GUI, business rules and database access would be good design. In the article with the title Single Responsibility Principle he specifically states the following

It is quite clear to me that “separation of responsibilities” and “separation of concerns” mean EXACTLY the same thing. Uncle Bob has never written an article which says they are different, but he HAS written an article where he uses the two terms to convey the same idea.

If SoC was different from, yet as important as SRP, then why does it not have its own place in the SOLID principles? I will tell you why not - BECAUSE MOST REASONABLE PEOPLE TAKE IT THAT THEY MEAN THE SAME THING!

Why then are:

  • There two wikipedia articles, one for each?
  • there two different terms that mean the same thing, used by the same author? Wouldn’t Robert C. Martin just not use the term “SoC” if he was using “SRP” and “SoC” interchangeably?

“most reasonable people”. Considering you’re the only person saying this and you have proven yourself to be completely unreasonable (Uncle Bob is right or wrong depending on where I can take him out of context or not) this statement is a blatant lie. Again, Nobody apart from you is saying they’re the same. You haven’t provided any sources for this claim.

This is from the book Clean Code by Robert C. Marin:

An optimal system architecture consists of modularized domains of concern, each of which
is implemented with Plain Old Java (or other) Objects.

Oh look, a Concern is made up of objects multiple objects.

The title is “Separation of Concerns” yet it uses the word “responsibility” over 20 times. This means that the two terms are interchangeable and mean exactly the same thing.

It also does not say that they are different. It uses the two terms in the discussion of a single concept, so it is reasonable to assume that as far as that concept goes the two terms are interchangeable and mean exactly the same thing.

I disagree. It simply states that he took the idea which was originally branded as “separation of concerns” and renamed it as the “single responsibility principle”. Same idea, different names.

I disagree. SRP and SoC achieve the same results, therefore they are the same concept but with different names.

For what feels like the hundredth time:

The fact they use the same label is irrelevant. They could be called “Uncle Bob’s principle 1” and “uncle bob’s principle 2”. The words they use to describe the concepts are completely irrelevant! Again we’re back to this “Large means big so big bang theory is the same as large hadron collider” nonsense. Please stop focussing on the words and concentrate on the concepts!

This is by no means a reasonable assumption. There is nowhere there that means they mean the same thing. They are related concepts which is why they appear together.

But all you’re proving is that you don’t understand the difference between the concepts. Pointing at a hole in your knowledge to back up your claim is not a valid argument.

He doesn’t say that though does he? He specifically says he “consolidated” SoC with other concepts such as coupling. We’re back to “A cake and butter are the same thing because the cake contains butter” it’s nonsense. The fact that you don’t understand coupling probably isn’t helping you here either.

SRP is a stronger version of SoC. We have been saying this all along, and Uncle Bob says it himself in the article you’re pointing to.

Your argument is basically this:

“I don’t understand the difference between a cheetah and a leopard therefore they are the same thing.”

Just because you don’t understand the difference does not mean they are the same.

Where does it say that?

Wrong, wrong, wrong. Oh brother, you are sooo wrong. Let’s look at the use of the term responsibility in this article.


That is to say, no element should share in the responsibilities of another or encompass unrelated responsibilities.

Plural, as in, a concern has responsibilities. More than one class, because a class should only have one responsibility.

Separation of concerns is achieved by the establishment of boundaries. A boundary is any logical or physical constraint which delineates a given set of responsibilities.

We are back to a “set” of responsibilities. A SET Tony!

Though the process of achieving separation of concerns often involves the division of a set of responsibilities, the goal is not to reduce a system into its indivisible parts, but to organize the system into elements of non-repeating sets of cohesive responsibilities.

Oh, a beautiful sentence, which you should be choking on!

Third, the strategies required to ensure each component only concerns itself with a single set of cohesive responsibilities often result in natural extensibility points.

Set of cohesive responsibilities. A set. Not one. A set or them. A concern is a set of responsibilities, not just one.

Within large companies, ensuring that groups and sub-organizations are assigned a unique set of cohesive responsibilities helps to facilitate overall business goals by minimizing the coordination necessary between teams and maximizing the potential of each team to focus on their collective responsibility and center of competency. 

More than one again. Oh, but a set of responsibilities that belong to a team of people, who have a collective responsibility. Has nothing to do with SRP. NOTHING!

When responsibilities are properly delineated, problem identification becomes easier, resolution becomes faster, and personal accountability is increased.

No mention about SRP being the same as SoC.

Delegating concerns refers to the process of assigning the responsibility for fulfilling behavior to a subordinate component. This strategy separates the concerns of responsibility from execution, and is beneficial for designing components whose implementation details may vary depending on external conditions.

Ok, this is as close as you’ll get to the author saying SRP is in anyway similar to SoC, in that he mentions “components”. A class can be a component, but also a group of classes could also form a component. So you lose. He doesn’t mean at all that SRP and SoC are the same.


Not only that, it states:

natural extensibility points.

If we’re following SRP, a SRP following class won’t be extended because once it’s extended it doesn’t follow SRP (because it’s the old behaviour + the new behaviour). You either have a second class helping to fulfil the same concern, so multiple classes with different responsibilities are used to fulfil the same concern or you break SRP because you have to edit the the original class with the new behaviour.

In short: In SoC a concern can be fulfilled by one or more classes, in SRP a single class must only have one responsibility. SoC applies to a group of related classes, SRP applies to each class individually.

What’s most telling about Tony’s argument is that the best sources he could find don’t even back up his claims in the slightest despite his attempts at cherry picking.

I am not interested in those results. Saying that my code breaks the Single Responsibility Principle simply by counting the number of methods, variables and lines of code is unscientific, simplistic, irrational and quite puerile. I have followed the description of SRP according to what Robert C. Martin wrote in two different articles, I have achieved adequate separation by implementing both the 3-Tier Architecture and the MVC design pattern. The idea behind SRP is to strike a balance between cohesion and coupling, where high cohesion and low coupling are the idea, and I have met that ideall. By breaking a class into smaller units using unscientific and arbitrary rules I would be decreasing cohesion, increasing coupling and decreasing readability. This, according to what Tom DeMarco wrote in his paper Structured Analysis and System Specification, would not be a good idea.

Please do not try to lecture me on the quality of my code as I simply do not care about the opinions of those who put the following of rules before the creation of results. I am a pragmatist, not a dogmatist, and I will break as many rules as I see fit in order to achieve the results that both I and my customers expect. In the real world it is necessary to strike a balance between academic theory and commercial practicality.

The fact that you would use more and smaller classes in your applications is a matter of personal choice. You have to live with the consequences of your choices just as I have to live with mine, but please do not waste your time by castigating me for not making the same choices as you. I do not like the way that you think, and I will never follow your lead. Learn to live with that fact and move on to something more constructive.

This argument became moot when you said your 9000 line class could not be improved. You’ve said it’s “perfect” and doesn’t break any rules. Yet here you’re saying you’re fine with breaking rules?

The issue exists because you claim your 9000 line class follows SRP while at the same time saying you don’t mind breaking rules. The contradiction here is that you broke SRP but on one hand you’re claiming the class follows SRP and on the other you’re saying "I am a pragmatist, not a dogmatist, and I will break as many rules as I see fit in order to achieve the results that both I and my customers expect. "

If it were just the latter it would be fine. Just admit your class breaks SRP and stop trying to redefine it to fit the code.

And lets be clear, the class in question does not follow SoC either, it has knowledge of CSV formats (how the data will be displayed), PDF format (how the data will be displayed), buttons (display logic: “/ if TRUE drop any SUBMIT buttons after a validation error”), file pickers (user input/gui code), file upload logic (user input), pagination logic, query building logic, information about css classes (display logic), the file name of a download (display/output logic) and lots of business logic.

EXACTLY! If an article uses several different terms when discussing the same topic, but never explicitly says that they are different and explains why they are different, then they are the same. That is how the English language works, or isn’t English you first language?

Now you are being silly. That’s as daft as saying “Chalk is a rock, therefore all rocks are chalk” which I learned was wrong way back in primary school. If an article on gravity uses the term “gravity” and “attraction between bodies” then it is reasonable to assume that both terms mean the same thing. It would be unreasonable to assume otherwise.

Using the same logic Robert C. Martin’s article titled the Single Responsibility Principle quite clearly states “This is the reason we separate concerns” which therefore means that “separation of responsibilities” and “separation of concerns” are identical concepts. The words are slightly different but the meanings are the same.

The English language is peculiar that way:

  • Different words can sometimes have the same meaning.
  • The same word can sometimes have different meanings.

An educated person would understand this and not jump to unreasonable conclusions.

I disagree. Each Model class contains code which executes the business rules required by that class. That is precise, not vague.

Only the concrete class, not the abstract class. It should be obvious to EVERY programmer out there that if a business rule changes then the code which executes that rule also has to change. This is a fact of life, and there is no technique or principle that you can devise which can escape that simple fact.

Now you are joking! No sensible programmer would ever do such a thing as it would decrease cohesion and increase coupling, which is the EXACT OPPOSITE of what you are supposed to do.

Your entire argument rests on: “I don’t understand the difference between a leopard and a cheetah therefore they are the same”. This is an argument from ignorance. Just because you don’t have the capacity to understand the difference does not mean they are the same.

As I said, it can apply to almost any class you can dream of. This version of the class:

class Default_Table
    // member variables
    var $access_count;                  // count of accesses since instantiation
    var $allow_empty_where = false;     // switch to allow an empty $where string in STD.LIST2.INC
    var $allow_db_function = array();   // allow a field's value in a database insert/update to contain a function name
    var $allow_scrolling = false;       // used inside ADD2 pattern to allow scrolling between selected rows
    var $alt_language_table;            // table holding alternative language text
    var $alt_language_cols;             // columns holding alternative language text
    var $audit_logging;                 // yes/no switch


Also meets that definition. A tiny subset. As such, you’re not defining what the class does. Your explanation needs to

What? that’s nonsense:

class X {

	public function foo() {
		echo 'foo';

I can change this to:

class X {

	public function foo() {
		echo 'bar';

and the code which executes it does not need to change. You’re full of nonsense yet again. There is no fact here, there’s a vague assertion.

Answer the question please:

What is the single reason to change for this class?

Keep in mind that if I can remove any of the methods or properties from the class and it still meets the definition you provide, you’re not describing what the class does because removing those methods is a change and that change does not affect the definition: it’s a different responsibility. If I can change the class API in any way and it still meets the definition you provide, you’re not describing all of what the class does because that is another reason to change.

What are you talking about? Splitting a class into two always reduces coupling. Two methods in the same class are by definition tightly coupled. Yet another demonstration of your lack of understanding of coupling.

At least we are getting Tony closer to the truth. He is saying he breaks rules, when he needs to. That is certainly a big step in the right direction, than we have been at.

Yes, he breaks rules. And if that gets him the results he and his customers want, that is fine and dandy.

The issue is the fact that you, Tony, are often trying to pass off your coding as “good” and “within the rules”, or good and purposely outside of the rules (like when it comes to DI), when your code simply isn’t good from a coding perspective. From a client/ user perspective, it might be fabulous. And that is great if it is. It still can’t be a given, that poor coding, although it works, can be considered good coding. It simply doesn’t work that way.


I think this is Tony’s biggest problem. He argues from the perspective “My code works” and then retrospectively tries to apply best practices to the code. When he can’t do this, he has to redefine the concept to match the code… which obviously doesn’t work.

I’ve asked this again but it’s worth repeating:

Tony: Why are you here? What are you trying to prove by trying to redefine SRP and SoC? You’re the only person in the world making this claim. Why? You have nothing to back it up, you have zero qualifications, zero credibility and zero authority, what makes you think you know better than everyone else?.. and most importantly… what does it matter? You go and code 9000 line classes full of bad practices, leave the rest of us in peace.

Some people like my framework, some people don’t.
Some people like the Zend framework, some people don’t.
Some people like the Laravel framework, some people don’t.
Some people like the Symfony framework, some people don’t.
Some people like the CodeIgniter framework, some people don’t.
Some people like the Yii framework, some people don’t.
Some people like the framework, some people don’t.

What does this prove? To each his own. This is a free country, and people are free to determine for themselves what they like and what they dislike.

But that is not all that my transaction generation process does. For example, the most common transaction pattern in all the applications which I have built is the LIST1. This is part of a family which also includes the ADD1, ENQUIRE1, UPDATE1, DELETE1 and SEARCH1 patterns. When you create a LIST1 task it performs the following:

  1. Generates the transaction script for the LIST1 task.
  2. Adds the LIST1 task to the TASK table in the MENU database.
  3. Adds the LIST1 task to the MENU table in the MENU database.
  4. Generates the transaction scripts for the associated ADD1, ENQUIRE1, UPDATE1, DELETE1 and SEARCH1 tasks.
  5. Adds ALL these task to the TASK table in the MENU database.
  6. Adds ALL these task to the NAVIGATION table in the MENU database.

This means that the LIST1 task will be instantly available on that subsystem’s menu bar, and all the associated tasks will be available on the LIST1 task’s navigation bar. All these tasks will be runnable with default behaviour but without having to write a single line of code - no PHP, no HTML no SQL. Can YOUR framework do that?