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

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.

http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/

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.

Scott

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.

Scott

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?

If you want to post sample code in a PHP discussion group then make it PHP code. It is called “common sense”.

Simply put: it doesn’t need to because putting it together doesn’t require so many repeated steps each time I want to add something… as I said, it violates DRY.

If you want to discuss Object-Oriented Programming principles then using you use an Object-Oriented Programming language. It’s called “common sense”. The fact that you don’t understand the similarities between the languages further demonstrates your lack of understanding of OOP.

You missed the point. I was applying sarcasm. You continuously believe that if the end result between two processes/concepts is the same, then the two items involved are identical. Yet, you claim Java and PHP are not the same, even though their end result is.

Which just goes to show that you have a particular set of beliefs that you place above everything else. If you believe SoC and SRP are the same, it doesn’t matter how much we show you they are indeed different, you will continue to see them as the same.

Just like boiling water via induction versus placing a pot of water on an open fire are entirely different, but they both result in the water boiling. How they did it greatly differs. SoC and SRP are those two different techniques.

Because they were created by different people who knew the same concept by different names.

Why don’t you ask him why he chose to say “This is the reason we separate concerns.” in an article about SRP? Those two terms still mean the same thing, which is also why they appear in http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/

I have provided several sources which dispute your claim, yet you continually fail to accept them.

Wikipedia has a process for this, you’ll often see pages have been merged. Try again.

Again focussing on the words and not the concepts

“Large hadron collider = big bang theory because they both use the word ‘big’”. Yet again all you’re doing is proving that you understand the words but not the concepts the words are used to label.

You have provided zero souces. The ones you did don’t back up your claim as pointed out here:

and here:

http://www.sitepoint.com/community/t/would-you-agree-this-is-the-definition-of-a-php-framework/191138/263?u=tomb

Which you ignored.

Your argument is an argument from ignorance. As I said before, it rests entirely on the fact that you don’t understand the difference between the two concepts. Pointing out your own ignorance to back up your claim doesn’t work.

http://rationalwiki.org/wiki/Argument_from_incredulity

The general form of the argument is as follows.
Minor premise: One can’t imagine (or has not imagined) how P could be so.
Major premise (unstated): If P, then one could imagine (or would have imagined) how P could be so.
Conclusion: Not-P.

Your argument is:

“I don’t understand the difference between SoC and SRP”
“Therefore there is no difference”

I don’t really understand the difference between an electron and a photon but I don’t go around saying “That means they’re the same thing”