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

PHP
#247

@tony_marston. Here’s the output of PHPMD (PHP Mess Detector) for your default_table class:

What you might find particularly interesting are the lines:

/home/tom/Downloads/radicore/std.table.class.inc:7      The class Default_Table has 8961 lines of code. Current threshold is 1000. Avoid really long classes.
/home/tom/Downloads/radicore/std.table.class.inc:7      The class Default_Table has 342 public methods and attributes. Consider to reduce the number of public items under 45.
/home/tom/Downloads/radicore/std.table.class.inc:7      The class Default_Table has 110 fields. Consider to redesign Default_Table to keep the number of fields under 15.
/home/tom/Downloads/radicore/std.table.class.inc:7      The class Default_Table has 169 methods. Consider refactoring Default_Table to keep number of methods under 10.
/home/tom/Downloads/radicore/std.table.class.inc:7      The class Default_Table has an overall complexity of 1585 which is very high. The configured complexity threshold is 50.

and the multiple occurrences of:

The method getData_serial has a boolean flag argument $unbuffered, which is a certain sign of a Single Responsibility Principle violation.
 The method reset has a boolean flag argument $keep_orderby, which is a certain sign of a Single Responsibility Principle violation.

..etc
#248

none of that implies you have to write no code, because you obviously have to write some code to call the framework.

Agreed. But the amount of code should be very small, and in a REALLY good framework this code would actually be generated for you by the framework itself, just as it is in RADICORE.

#249

[citation needed]. Sorry this just isn’t true… and by no metric is radicore a “really good” framework.

edit: Whether it’s generated for you or not is 100% irrelevant. I’d argue that if code is structured in such a way that it can be “generated for you” then it’s poorly designed and likely breaking DRY. How similar is this generated code? If it’s generated then i’m going to assume very… breaking DRY.

#250

They use the two terms in the same article without saying that the two terms are different, which confirms that they have the same meaning. That is not a big leap, it is a reasonable interpretation.

They both talk about breaking a program down into smaller units such as “sections” or “modules”. Both of those Wikipedia articles specifically use the word “class”. It is true that a “section” might be something like the Presentation/GUI layer in the 3-Tier Architecture which can be broken down into a separate Controller class and a View class, but that simply means that the smallest unit is still a class.

As for your Java examples, they are irrelevant as this is a PHP group, and everybody knows that PHP and Java are different languages which work differently.

When the processing of business rules for a database table needs to change. Is that simple enough? Bear in mind that I do not try to reclassify “business rules” into different categories so that different rules go into different classes. Even Robert C. Martin never suggested that.

You should also remember that my Default_Table class is an abstract class which is inherited by every one of my 300+ Model classes. Each of these concrete classes does not need to contain code for any method except for when it needs to override the default behaviour, in which case all the developer has to do is copy in the relevant customisable method (with a “cm” prefix) into which he can then insert code. Each concrete class therefore contains only a small number of methods, about 6 on average.

#251

Sorry, what? So any article that uses two different terms without explicitly stating they are different means they are the same?

So by this definition:

Gravity or gravitation is a natural phenomenon b

Gravity is a natural phenomenon and all natural phenomenons are gravity. It doesn’t state anywhere that they’re not the same!! Do you even think before you type? You’re so far down this avenue of insanity you’ve lost all perspective.

https://en.wikipedia.org/wiki/Object-oriented_programming

You seem again to be making a distinction which isn’t there. They are two programming languages. We’re discussing OOP principles and the principles apply to OOP, not to a specific language. Try again. In PHP we build the GUI using template engines and form classes. I can use DomDocument, DomElement and other related classes to build the HTML. This would still follow SoC. However, if I merged the code for the template engines, form classes and DOM manipulation it would violate SRP.

It’s incredibly vague. By this definition I could removed all the methods from the class and still use this definition or I could apply it to this class:

class BusinessRules {
 public $exists = false;
}

Also it admits to breaking SRP:

If any of the business rules change, the class needs to change. How many business rules are there? Well it doesn’t matter because you specifically said rules. If we were following SRP, each rule would have its own class.

#252

You may not think so, but both my previous and current business partners, and the customers who use it on a day-to-day basis to conduct their business, would disagree with your opinion. THEIR opinion is much more valuable to me than yours, so you might as well keep your opinion to yourself.

Each of the 2,500+ transactions in my application has its own transaction script, as described in http://www.tonymarston.net/php-mysql/infrastructure.html#component.script, which looks like the following:

<?php
$table_id = "person";                      // identify the Model
$screen   = 'person.detail.screen.inc';    // identify the View
require 'std.enquire1.inc';                // activate the Controller
?>

Each script therefore specifies a unique combination of Model, View and Controller, therefore there is no violation of DRY.

#253

Then stop coming here and trying to convince people your framework is “good”.

You do realise it would take longer to navigate into a GUI, move between form fields and type into text boxes than it would to just type out the code in the first place?

#254

I have already provided links to such articles in post #225, so here they are AGAIN

#255

For at least the fifth time: There is nothing in those articles that says SoC and SRP are the same thing.

http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/
This one doesn’t even mention SRP

This one mentions them both but doesn’t say they’re the same

http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html

This one by Robert C. Marin actually states they are different:

Two years later, Edsger Dijkstra wrote another classic paper entitled On the role of scientific thought. in which he introduced the term: The Separation of Concerns.
The 1970s and 1980s were a fertile time for principles of software architecture. Structured Programming and Design were all the rage. During that time the notions of Coupling and Cohesion were introduced by Larry Constantine, and amplified by Tom DeMarco, Meilir Page-Jones and many others.
In the late 1990s I tried to consolidate these notions into a principle, which I called: The Single Responsibility Principle. (I have this vague feeling that I stole the name of this principle from Bertrand Meyer, but I have not been able to confirm that.)
The Single Responsibility Principle (SRP) states that each software module should have one and only one reason to change. This sounds good, and seems to align with Parnas’ formulation. However it begs the question: What defines a reason to change?

He specifically states he combined several already defined concepts and called it SRP. Saying SoC is the same as SRP is like saying “A cake and butter are the same thing because the cake contains butter”.

It’s impossible to have SRP without SoC but it’s not impossible to have SoC without SRP. One is more refined than the other.

#256

What!!! But the end result is the same… a web page/application that accepts user input and renders output. How can they be different when the end result is the same!!! mind blown

1 Like
#257

In both articles Uncle Bob states that separating out the logic for the GUI, business rules and database access would be good design. In the article with the title Single Responsibility Principle he specifically states the following

It is quite clear to me that “separation of responsibilities” and “separation of concerns” mean EXACTLY the same thing. Uncle Bob has never written an article which says they are different, but he HAS written an article where he uses the two terms to convey the same idea.

If SoC was different from, yet as important as SRP, then why does it not have its own place in the SOLID principles? I will tell you why not - BECAUSE MOST REASONABLE PEOPLE TAKE IT THAT THEY MEAN THE SAME THING!

#258

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.

#259

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.

#260

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.

#261

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.

#262

Where does it say that?

#263

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

#264

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.

800×800 63.3 KB

#265

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.

#266

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.