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.
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.
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.
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.
“A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties”
A interfaceS, dependencieS. A component is not a single class. Again, we come back to your misunderstanding of the difference between Separation of Concerns and Single Responsibility Principle.