All of the code that you reference in the article you linked to is executed after control is handed off to the framework, by the framework itself. The amount of code required to call the framework is very minimal. Regardless, none of that implies you have to write no code, because you obviously have to write some code to call the framework.
@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
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.
[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.
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.
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.
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.
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.
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?
I have already provided links to such articles in post #225, so here they are AGAIN
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.
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
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!
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.
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.
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.
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.
Where does it say that?
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
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.
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.