But what if you are using a Front Controller and a Router? Surely the application starts at the Front Controller and the Front Controller is part of the framework? Or are you saying that you have to write your own Front Controllers and Routers?
Yet my definition of a framework agrees completely with the four characteristics described in https://en.wikipedia.org/wiki/Software_framework. All you have done is proved that different organisations have different definitions of a framework, and that it is impossible to create something which conforms to all of these definitions.
I will stick with that Wikipedia article and the definition found in http://ifacethoughts.net/2007/06/04/difference-between-a-library-and-a-framework/
Answer this with a yes or no:
Are you honestly suggesting that wikipedia, with a  on main point you’re quoting about default behaviour holds more authority than:
- An academic paper from CERN relating to work on the LHC
- An academic paper from Manchester University that describes a specific framework
All you have done is prove that Robert C. Martin can contradict himself in two separate articles. The book was published in 2012 while http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html was written in 2014. I can only conclude that Uncle Bob came to his senses and revised his opinion. I prefer to stick with his later opinion.
Apart from that, The primary rule of encapsulation is that ALL the properties and ALL the methods for an entity should be placed in the SAME class, so breaking a class into artificially smaller units just to satisfy a count up to an arbitrary number does not smell right to me.
In the MVC design pattern both data validation and business rules belong in the Model, and not in either the View or the Controller, so to say that they do not belong in the same Model class is patently wrong.
At what point does he contradict himself? There is nothing in that article about class size and certainly doesn’t state anything about “revising his opinion”. He’s still advertising the book on his website so clearly he stands by it.
Are you a troll tony? I have to wonder why you come here and argue against things like academic papers, respected authors like Robert C. Martin and things written by companies like google and microsoft. What is it you’re trying to achieve?
And we’re back to what Scott was trying to tell you about SRP and SoC. A single concern can be fulfilled by multiple classes which collaborate with each other, a single class should have a single responsibility.
MVC is about Separation of Concerns, not single responsibility.
WHAT!!! Are you seriously saying that I should put View logic into the Model??? What kind of programmer ARE you?
Your reference in post #118 was to a book he published in 2012 whereas my reference was to an article he wrote in 2014 which CLEARLY shows a change of opinion in which he wrote
He is clearly saying that GUI logic, business logic and database logic should be separated into different components, which is EXACTLY what I have done.
Where did I say that?! I clearly said you broke encapsulation by separating the data and the methods that work on that data. The data is in the model and the methods that work on the model is in the view: Encapsulation has been broken. I’m suggesting you have a poor separation of concerns.
Nowhere does that article demonstrate a “change of opinion” You are seeing what you want to see, because he certainly does not demonstrate a “change of opinion”. He says they are different concerns that change at different times and mentions nothing about class size.
You’re trolling at this point.
I can only repeat what is I said in post #90
Just because you find articles which offer a different definition than the one found in https://en.wikipedia.org/wiki/Software_framework does not means that those articles are correct. As far as I am concerned they are merely offering different opinions, and I do not agree with those opinions.
There is no reference to size in his 2014 article, so “too big” or “to small” are irrelevant when in comes to splitting a monolithic piece of code into smaller units. His 2014 article specifically states that ALL GUI logic should be in its own component (although I have actually split that into separate Views and Controllers), ALL business logic should be in its own component, and ALL database logic should be in its own component. There is absolutely nothing in that article which states that if any of that logic exceeds a particular method count or line count that the component should be split into smaller sub-components.
I have never seen ANY definition of MVC which states that you need more than three classes to implement it. There may be multiple variations for each of those in an application, but each user transaction should be able to operate with no more than one of each.
Unlike you can point to any authoritative article on MVC which identifies why and how each of those three components needs to be split it smaller sub-components I will continue to treat your argument as utterly bogus.
Having data in the Model and logic in the View which presents that data in a particular format for the user such as HTML PDF or CSV does NOT break encapsulation. The Model class is only responsible for obtaining the data and validating it according to the business rules. It passes that data to a separate Data Access Object when it needs to be stored in the database and to a separate View when it needs to be shown to the user.
You are trying to tell me that if I apply SRP/Soc then I am automatically breaking encapsulation!!! What a totally ridiculous argument!!!
Can you specify what constitutes ‘authoritative’ in your mind? You’ve already shown you will happily cite or dismiss the same sources and authors depending on whether they support your argument or not.
Please answer with a yes or no. Is a line on a wikipedia page with  worth more than academic journals and examples from google, apple and microsoft?
To be clear. If a class can be separated into two or more other classes that change for different reasons or at different rates; then that separation conforms to the Single Responsibility Principle.
The main idea is to gather together the things that change for the same reasons and at the same rates. Keep separate those things that change for different reasons or at different rates.
Thanks for the clarification! This is the class in question:
Would you say this followed your definition of SRP or not? @tony_marston404 is citing your definition to claim it does.
Laravel does exactly that as well, yet you dismiss it as “not a framework.”
Does “basic and default behavior” !== “do anything”? I’m not sure what your objection is. Laravel comes with a set of base classes with “basic and default behavior” that you can extend with your own custom code if you want it to do more.
Errrr, no. Laravel comes with those and controls the flow of execution through them.
Tony thinks separation of concerns and SRP are one and the same. So, because his framework follows MVC, thus obeying SoC, all of it then automatically obeys SRP too.
The contradiction he accuses Bob of making comes from his clear misunderstanding of the two concepts, which differ only in scope basically. SoC’s scope is at a higher framework/ application level. Like…separation of concerns between areas of the framework and application to split them up in logical parts, so they are more modular, reusable and easier to change.
SRP’s scope is at the lower class level. It describes how classes should be formed, so they are also more modular, reusable and easier to change. The goals of both concepts are the same, however, you can’t always say you have successfully complied with SoC and it directly means you have properly done SRP too.
If you see the two concepts like that, then everything Bob has said makes perfect sense and we are back to Tony’s 9000 line class breaking SRP.