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

[s_molinari]

@tony_marston404

The methods fall into one of the following categories

1. Methods which allow it to be called by the layer above it (the Controller or the View)
2. Methods which allow it to call the layer below it (the Data Access Object).
3. Methods which sit between these two. Many of these are “customisable” methods which are empty, but could be filled with code in order to override the default behaviour.

Wouldn’t you say these are 3 different responsibilities? If not, why not?

And, continuing on this line of thought, you noted a very good quote about SoC. Here it is again.

@tony_marston404

The Principle of Separation of Concerns states that system elements should have exclusivity and singularity of purpose. That is to say, no element should share in the responsibilities of another or encompass unrelated responsibilities. 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.

You nicely highlight the word responsibility, but ignored what is being said. Look at the last sentence.

A boundary is any logical or physical constraint which delineates a given set of responsibilities.

Responsibilities, not responsibility. It is plural, not singular. In other words, they could have written this.

A boundary is any logical or physical constraint which delineates a given set of classes, where each class represents a single responsibility.

So, can you now still stay so stubborn and insist SRP and SoC are the same thing? I’ll answer it for you. You can’t. You cannot use the definition of SoC to legitimize your monster class and at the same time use that definition to say your monster class also follows SRP. The above proves SoC and SRP are two different concepts. And thus, we are back to your monster class breaking SRP.

Scott