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

You have obviously forgotten that the title of this thread is “Would you agree that this is the definition of a PHP framework?” In post #4 you referred to a definition of a framework in https://en.wikipedia.org/wiki/Software_framework and also http://ifacethoughts.net/2007/06/04/difference-between-a-library-and-a-framework/. In post #15 I agreed with the definitions in those articles but not with some of your other comments. In post #16 I described how Radicore met the four characteristics of that wikipedia definition but without discussing the code that I used to do it. If you read the subsequent posts you will clearly see that it is YOU and your partner-in-crime @TomB who wandered off the topic in this discussion and started to attack my coding style and my failure to adhere to your version of “best practices”.

If you want this discussion to stay on-topic then I suggest that YOU stop making posts which are off-topic. As long as you keep attacking me I reserve the right to defend myself.

You should also learn to stop contradicting yourself in your attacks as it clearly shows that you haven’t a clue what you are talking about and are simply throwing mud for the sake of it. For example, in http://www.sitepoint.com/community/t/dependency-injection-breaks-encapsulation/113596/167 you accuse my abstract Model class of being a “monster class” which does too much, but then in http://www.sitepoint.com/community/t/would-you-agree-this-is-the-definition-of-a-php-framework/191138/30 you accused it of being an “anemic domain model” which doesn’t do enough. Which is it? Too Much or Not Enough? It cannot possibly be guilty of both.

You also claim that my abstract Model class breaks SRP/SoC simply because it has 120 methods. Everybody knows that SRP/SoC has nothing to do with counting methods or lines of code, it is about the separation of responsibilities or concerns. Robert C. Martin had this to say on that subject in his article http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html

He is saying quite clearly that in a “good design” the logic for GUI. business rules and database should be separated. This description matches the 3-Tier Architecture EXACTLY and which is EXACTLY what I have implemented. Not only that I have also incorporated the MVC design pattern for good measure. My implementation matches Robert C. Martin’s description to a tee, so when you say that my implementation is wrong you are also saying that Robert C. Martin is wrong.

What is YOUR definition of SRP/SoC and why is it so much better than Robert C. Martin’s?

This is an excerpt from the book Clean Code by Robert C. Martin:

Classes Should Be Small!
The first rule of classes is that they should be small. The second rule of classes is that they
should be smaller than that. No, we’re not going to repeat the exact same text from the
Functions chapter. But as with functions, smaller is the primary rule when it comes to
designing classes. As with functions, our immediate question is always “How small?”
With functions we measured size by counting physical lines. With classes we use a
different measure. We count responsibilities.1
Listing 10-1 outlines a class, SuperDashboard, that exposes about 70 public methods.
Most developers would agree that it’s a bit too super in size. Some developers might refer
to SuperDashboard as a “God class.”

He specifically says that 70 methods is too much. He goes on to say:

Five methods isn’t too much, is it? In this case it is because despite its small number
of methods, SuperDashboard has too many responsibilities.
The name of a class should describe what responsibilities it fulfills. In fact, naming
is probably the first way of helping determine class size. If we cannot derive a concise
name for a class, then it’s likely too large. The more ambiguous the class name, the more
likely it has too many responsibilities. For example, class names including weasel words
like Processor or Manager or Super often hint at unfortunate aggregation of
responsibilities.
We should also be able to write a brief description of the class in about 25 words,
without using the words “if,” “and,” “or,” or “but.” How would we describe the
SuperDashboard? “The SuperDashboard provides access to the component that last held the
focus, and it also allows us to track the version and build numbers.” The first “and” is a
hint that SuperDashboard has too many responsibilities.

and

To restate the former points for emphasis: We want our systems to be composed of
many small classes, not a few large ones. Each small class encapsulates a single responsibility,
has a single reason to change, and collaborates with a few others to achieve the
desired system behaviors.

You have repeatedly stated that your system is “a few large ones”. And let’s be clear, he called a 70 method class too large, your 120 method class is nearly double that.

He also says:

Classes should have a small number of instance variables. Each of the methods of a class
should manipulate one or more of those variables. In general the more variables a method
manipulates the more cohesive that method is to its class. A class in which each variable is
used by each method is maximally cohesive.

Your class has about 50 variables, some of which aren’t used in the class and it’s impossible to sum up. So let’s turn it around: What is YOUR definition of SRP/SoC and why is it so much better than Robert C. Martin’s?

1 Like

No, they are NOT different. They both talk about “separation” and breaking down code into smaller modules. If you ask the average programmer to specify the difference between a “concern” and a “responsibility” you will find that there are none. You cannot apply these two principles to the same piece of code and get different results so they are the same.

I prove no such thing. I have clearly implemented the MVC design pattern as I have different components for the Models, Views and Controllers and this conforms to the definition of SRP. I do NOT have a monster Model class for the entire application, I actually have a separate Model class for each table in my database (and my application has over 300 tables). So each Model class is responsible for the validation and business rules for a SINGLE database table, so again it matches the “Single Responsibility Principle”.

SRP is violated when there is more than one “reason to change”

  • Changing the validation is a reason to change
  • Changing the business rules is a reason to change

The class does too much and breaks SRP.

Not according to Robert C. Martin’s definition of “reason to change”.

Wrong. That is a variable in the Model which is passed to the View object which is responsible for the production of PDF documents.

Wrong. That is a variable in the Model which is passed to the View object which is responsible for the production of CSV files.

All your accusations are wrong. Those are simply variables which are defined in the Model but which are passed to other objects for the actual processing. It is these other objects which contain the logic which deals with the contents of those variables so to say that my Model class contains too much logic is completely bogus.

Excellent then you also have broken encapsulation. You’ve quoted this exact definition before:

Encapsulation is the packing of data and functions into a single component. The features of encapsulation are supported using classes in most object-oriented programming languages, although other alternatives also exist.

A language construct that facilitates the bundling of data with the methods (or other functions) operating on that data.

You have just said you have the data in the model and the functions in the view. The data and functions are in different components. So that’s two for two.

Wrong again. I quoted Robert C. Martin in #118

Completely wrong, as usual. In the first place it is my framework which contains the most reusable components as I have used it to build several different applications. It is the framework that supplies the Controllers, Views and Data Access Objects, while each application provides nothing but the Models.

In the second place my main enterprise application is comprised of 9 modules each of which has its own database as well as being able to share components from other modules.

You can use my framework to create you own applications, but you cannot take one of my application components and reuse it in your application.

Nowhere in the Wikipedia definition of a framework does it say that the developer has to write code to call the framework before the framework takes control. While a little code may be necessary in order to tell the framework which application component to run, it should be so little and so simple that the framework should be able to generate it for you. That is exactly what Radicore does.

You aren’t reading what I wrote. I said that you don’t have to write any code in order to generate components which have basic and default behaviour, but you DO have to write code in order to change or enhance that default behaviour.

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 [citation needed] 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
  • Apple
  • Google
  • Microsoft

combined?

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.