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

[TomB]

@tony_marston404

He is redefining the concept of SoC, but including references to coupling and cohesion and giving it a different name.

Different name, same concept.

REDEFINING. Do you know what this means? It means “Giving a new meaning”. Different meaning = different concept.

[tony_marston404]

@TomB

What is it you’re trying to achieve by incorrectly stating that SRP and SoC “ARE EXACTLY THE SAME!!!” why are you here debating this? What difference does it make to you? Your code breaks SRP? So what? Who cares, you’re the only one who has to live with it.

If I am indeed the one who has to live with it then why are YOU arguing? I have applied MY interpretation of SRP and created a class that is bigger than one which you would have created. So what? How does that affect you? Am I asking YOU to change YOUR methodology?

[TomB]

@tony_marston404

If I am indeed the one who has to live with it then why are YOU arguing? I have applied MY interpretation of SRP and created a class that is bigger than one which you would have created. So what? How does that affect you? Am I asking YOU to change YOUR methodology?

I am trying to prevent you spreading erroneous information on a public message board where there are developers, like yourself, of a low skill level. These developers will be heavily set back if they come across your posts and don’t see them properly critiqued.

[s_molinari]

@tony_marston404

I am saying that no sensible programmer would apply SoC and then apply SRP on the same piece of code. He would either apply the concept under the label SoC OR he would apply it under the label SRP.

But a developer would use both and should. SoC should be used for separation of layers (sets of responsibilities) and SRP at the class level, to make sure a class has only one reason to change.

I think Bob also extended this meaning of “reason for change” to envelope SoC into SRP.

So, SoC is SRP at a layer (set of responsibilities) level of the software, where concerns need to be separated. But, SRP at the class level means the class has only one responsibility and thus, will and should have only one reason to change.

You, however, only look at the layer level of the definition and say your 9000 line class fits that definition. Where you err is saying, because your 9000 line class fits the layer level definition, it automatically fits the class level definition too. In other words, if we hold Bob’s definition as the “last version”, it can be actually used for two use cases. Separating responsibilities between layers of the software and singling out responsibilities into classes, so they only have one.

It is all academic, because your 9000 line class breaks both use cases of SRP.

Scott

[mAAdhaTTah]

@tony_marston404

If you say so. I am not going to argue this point any further.

…what an anticlimactic victory.

[tony_marston404]

@TomB

REDEFINING. Do you know what this means? It means “Giving a new meaning”. Different meaning = different concept.

No, he is redefining an old concept with new terminology. SRP can be treated as a modern replacement for SoC. It is still the same underlying concept, but described using more modern terminology.

[TomB]

@tony_marston404

No, he is redefining an old concept with new terminology. SRP can be treated as a modern replacement for SoC. It is still the same underlying concept, but described using more modern terminology.

[citation needed]

That is not what redefining means. Redefining means, surprisingly “Giving a new definition” New definition = new meaning, new concept.

Let’s put it this way. SRP is defined as “Reason to change”, this is not mentioned anywhere in SoC. How are they the same?

[tony_marston404]

@DaveMaxwell

As for this class, the number of methods can be reduced because there are a number (I count 60+) which simply return the passed in variables. My guess is the methods are placeholders which were built JUST IN CASE something needed to be done in that situation.

These are GETTER methods which, according to the paradigm police, are supposed to be used instead of directly accessing object variables. This is supposed to be the “right way” is it not, or have I been misinformed AGAIN? Has some guru on this forum been spreading porky pies?

@DaveMaxwell

There’s also another (deleteRelations) which could be removed with proper DB setup.

Perhaps you are not aware that the deleteRelations method is in the Model class in case there are business rules which would prevent a record from being deleted. If a deletion is allowed then control is passed to the database object so that it can construct and execute the relevant SQL query.

[tony_marston404]

@TomB

That is not what redefining means. Redefining means, surprisingly “Giving a new definition” New definition = new meaning, new concept.

You can redefine the same concept in different ways using different terminology, but it is still the same concept.

[TomB]

@tony_marston404

Perhaps you are not aware that the deleteRelations method is in the Model class in case there are business rules which would prevent a record from being deleted. If a deletion is allowed then control is passed to the database object so that it can construct and execute the relevant SQL query.

Surely deciding whether a deletion is allowed is *gasp* a responsibility.

[TomB]

@tony_marston404

You can redefine the same concept in different ways using different terminology, but it is still the same concept.

Redefine = Change = There is a difference between them.

Did you even read any of my posts? You have said:

Uncle Bob is saying that SRP has replaced SoC because SRP now includes the ideas of Coupling and Cohesion which SoC did not.

If one includes two ideas that the other does not, how are they describing the same concept? They are clearly different concepts… because they have different definitions. Or are you going to try to redefine the word “concept” now?

Not only that, he describes SRP as “Reason to change” this is not mentioned anywhere in “SoC”, so they are clearly different concepts.

edit: Answer this: How are two things “EXACTLY THE SAME” when the definition of one includes the definition of the other + other concepts?

Again, you haven’t answered the question, if SRP is:

SoC + Coupling + Cohesion

How can SRP be the same as SoC, if that were the case SoC would already include Coupling and Cohesion.

[DaveMaxwell]

@tony_marston404

These are GETTER methods which, according to the paradigm police, are supposed to be used instead of directly accessing object variables. This is supposed to be the “right way” is it not, or have I been misinformed AGAIN? Has some guru on this forum been spreading porky pies?

Sorry, but methods like these are not getters. It’s returning the parameter passed to the method.

    function _cm_validateInsert ($rowdata)
    // perform custom validation before an insert.
    // if anything is placed in $this->errors the insert will be terminated.
    {
        // customisable code goes here
 
        return $rowdata;
 
    } // _cm_validateInsert

@tony_marston404

Perhaps you are not aware that the deleteRelations method is in the Model class in case there are business rules which would prevent a record from being deleted. If a deletion is allowed then control is passed to the database object so that it can construct and execute the relevant SQL query.

You lost me here. So sometimes child records are deleted, and sometimes they shouldn’t? Orphaned records are NEVER a good idea. Controlling child/foreign key records through the DBMS is almost always the better approach, and almost always faster.

[TomB]

@DaveMaxwell

Sorry, but methods like these are not getters. It’s returning the parameter passed to the method.

What he’s doing here is assuming that a subclass will override the method and add some logic. It’s a very poor way of achieving this modularity but I can see why he’s done it.

[DaveMaxwell]

@TomB

What he’s doing here is assuming that a subclass will override the method and add some logic. It’s a very poor way of achieving this modularity but I can see why he’s done it

I can see that - it’s still not a getter, though. And completely unnecessary.

[myesain84]

I was curious about the content of the RADICORE framework several weeks (months ?) ago, and was prepared to register to download the source code from radicore.org . It is acceptable to have users register to view and use your copyrighted material, no arguments there.

It is unacceptable, however, to require personal information (including name and country) and a password to register, and have the content delivered over an insecure connection.

Can you provide either another copy of Radicore that is not behind an auth wall, or update your server to provide encryption so we can look at the full content?

[Lemon_Juice]

OMG, 175 new replies in this thread since yesterday! It has some interesting bits and I learned something more about a few programming concepts but I wish this whole discussion was 1000 times shorter…

Tony, you seem to clearly lack understanding of programming concepts and you have difficulties with reading source materials and misunderstand what they say. I think it would be better if you focus on topics where you have more expertise - for example, you could certainly provide some good points on producing software that works, selling to clients, what programming practices can bring most financial benefit - but what you are saying about programming concepts here only proves you understand little and in this discussion it does not matter how well your code works and how your clients are happy with it.

To the others, I don’t see any point in trying to convince Tony of these same truths for a 1000th time since he clearly is not willing to change his stance. Repeating the same argument over and over only leads to accumulation of posts that don’t bring anything new. Some people will always be opposed and fail to understand and that’s part of life.

[tony_marston404]

@DaveMaxwell

@tony_marston404

These are GETTER methods which, according to the paradigm police, are supposed to be used instead of directly accessing object variables. This is supposed to be the “right way” is it not, or have I been misinformed AGAIN? Has some guru on this forum been spreading porky pies?

Sorry, but methods like these are not getters. It’s returning the parameter passed to the method.

php
    function _cm_validateInsert ($rowdata)
    // perform custom validation before an insert.
    // if anything is placed in $this->errors the insert will be terminated.
    {
        // customisable code goes here
 
        return $rowdata;
 
    } // _cm_validateInsert

Sorry, I misunderstood the methods to which you were referring. Any method with a “cm” prefix is a customisable method which by default is empty so that it does nothing. It can be copied to the concrete class and filled with code so that the developer can alter the default behaviour. When a concrete class is initially created it does not contain any customisable methods, in which case it will only provide default behaviour.

@DaveMaxwell

@tony_marston404

Perhaps you are not aware that the deleteRelations method is in the Model class in case there are business rules which would prevent a record from being deleted. If a deletion is allowed then control is passed to the database object so that it can construct and execute the relevant SQL query.

You lost me here. So sometimes child records are deleted, and sometimes they shouldn’t? Orphaned records are NEVER a good idea. Controlling child/foreign key records through the DBMS is almost always the better approach, and almost always faster.

No, what I’m saying is that when performing a cascade delete there may be a rule that requires a value on a record to be checked before it is deleted, and if that check fails then neither it nor any of its parents can be deleted. This type of validation is quite rare, but I have encountered it, and it cannot be performed by the DBMS.

[tony_marston404]

@TomB

Surely deciding whether a deletion is allowed is gasp a responsibility.

It is just one of the many possible business rules that could be contained with the class which is responsible for that particular database table. The idea that each business rule should go in its own class is utterly preposterous. Besides that it would also violate encapsulation.

[tony_marston404]

@mAAdhaTTah

tony_marston404:
If you say so. I am not going to argue this point any further.

…what an anticlimactic victory.

However I will continue to argue the point that Laravel in particular is not a proper framework as it does not meet the description of characteristic #2 which states

default behavior: A framework has a default behavior. This default behavior must be some useful behavior and not a series of no-ops.[

If you look at http://www.sitepoint.com/crud-create-read-update-delete-laravel-app/ you will see how much code has to be written by the developer in order to create some basic CRUD screens. In a more advanced framework such default behaviour would be supplied automatically, and the developer would only be required to write code in order to override the default behaviour.

[tony_marston404]

@s_molinari

So, SoC is SRP at a layer (set of responsibilities) level of the software, where concerns need to be separated. But, SRP at the class level means the class has only one responsibility and thus, will and should have only one reason to change.

I disagree. SoC and SRP are exactly the same. Robert C. Martin says so, and so does the author of http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/ in a response to a question which I asked him yesterday.