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

No he doesn’t. He specifically says that SRP is a consolidation of SoC, Coupling and Cohesion which he describes as “Reason to change”. This is clearly not “exactly the same”. Once again your logic is entirely flawed:

You have reiterate this point yourself:

1 + 2 + 3 == 1 in this odd worldview of yours.

You’re saying:

SoC == SRP

And

SoC + Cohesion + Coupling == SRP

Therefore:

SoC + Cohesion + Coupling == SoC

Either coupling and cohesion are meaningless or your logic is severely flawed…

This argument still boils down to “I don’t understand the difference therefore they are the same”. Pointing out your own ignorance is not evidence to back up your claim. All it proves is that you don’t understand the concepts.

Having a method count which is greater than an arbitrary number does not guarantee that you have violated SRP, it merely suggests that you might have.

[quote=“tony_marston404, post:404, topic:191138”]
SRP is reasons to change, I’ve listed these multiple times in the thread and you’ve ignored them. [/quote]
You totally misinterpret “reason for change”. Robert C. Martin has clarified this in two separate articles in which he states the following:

He clearly states that that separating GUI logic, business logic and database logic is sufficient to satisfy SRP. This describes the 3-Tier Architecture which is precisely what I have implemented. You have chosen to interpret SRP in a more extreme way and aim to produce ever smaller and smaller classes. That is YOUR choice, not mine, and I see no reason why I should be bound by the incorrect choices that you make. In your ideal world you aim to produce classes which contain only one method each, and each method contains only a single line of code. What you fail to realise is that this approach violates all the basic principles of OOP:

  • you have broken encapsulation.
  • you have low cohesion
  • you have high coupling
    So by following you extreme misinterpretation of SRP you have gone beyond the aim of creating a system of cohesive modules and have ended up with a system full of tiny fragments where all cohesion has been lost. You simply cannot see that the results of your misinterpretation are wrong, all you can do is blindly follow your misinterpretation and assume that the results must automatically be acceptable. That is the definition of a dogmatist.

I, on the other hand, am a pragmatist. I apply a rule while it produces benefits and stop applying it when it does not. You do not know when to stop, and you simply cannot see that what you have created is less readable and therefore less maintainable.

Even if the customers have to enter their details themselves, that would still require 100 iterations of the “Create Customer” task.

If you new what you were talking about you would surely understand that the DRY principle refers to the avoidance of code which is repeated, not procedures which are repeated. This is yet another example of where you cannot stop mis-interpretting what a basically simple principle is supposed to mean.

Just because my opinion differs from your does not make it automatically wrong, just different. It is up to the individual reader to decide for himself/herself which opinion makes the most sense.

On one hand you say this, and on the other you say “My 9000 line class follows SRP”. This entire “i’m a pragmatist and don’t need to follow the rules” argument falls to pieces when you then claim “I’m following the rules”.

So everything you just posted is irrelevant if you’re claiming you’re following SRP. Are you following SRP or not? If you are then saying “I don’t need to follow the rules” is both irrelevant and erroneous because apparently you do need to follow the rules.

Bot SoC and SRP talk about breaking up a large piece of code into smaller units. In one principle these units are called “sections” “modules” or “classes” while in the other they are simply called “classes”. The concept is the same but the wording is different. What they both try to do is try to help you identify what pieces of the whole can be treated as a logical unit. SoC completely fails to identify adequately what is a “concern” while SRP quite clearly talks about GUI logic, business logic, and database logic as being separate “concerns” or “responsibilities”. Robert C. Martin says they are the same, so they are the same whether you like it or not.

“I don’t understand the difference between a leopard and a cheetah therefore they are exactly the same thing”

Tony I have a challenge for you. Given that you have said:

We can represent this in PHP as:

$SoC = 1;
$coupling = 2;
$cohesion = 4;

$SRP = $SoC + $coupling + $cohesion;

var_dump($SRP === $SoC);

Unless you can make that evaluate to true without making any of the values zero or negative (ie, meaningless or not actually included) or changing the definition of SRP so it doesn’t include all 3 concepts, or changing the comparison/operator to something other than equality or making it so they’re not compared (You are saying they are EXACTLY THE SAME after all), then your point is null and void.

I’m going to keep posting this code for you to fix until you do it or give up.

This argument still boils down to “I don’t understand the difference therefore they are the same”. Pointing out your own ignorance is not evidence to back up your claim. All it proves is that you don’t understand the concepts.

Why is that a poor method? It is called “method overriding” and is a standard feature of all OO languages.

http://www.objectmentor.com/resources/articles/inheritanceVsDelegation

I know you’ll struggle to apply the concepts and dismiss it because it “not to do with models” or some such nonsense, but try to understand it.

Why is it unnecessary? It is using “method overriding” which is a standard feature of all OO languages. It is the technique that I use to allow a developer to override the standard behaviour by providing code of his own in a method which is defined in the superclass but empty by default.

It has been that way since 2006 and nobody else has ever complained. All they do is enter duff information. The only reason I ask people to register is so that I can inform them of new versions. This notification can of course be turned off by individuals should they so wish.

Why would this a problem? There is nothing secret in the download that requires a secure connection.

I do not have the time to cater for individual requests.

Other than his/her personal details…

@myesain84: Given the lack of security in the RADICORE encryption class ( https://gist.github.com/ircmaxell/160b4a2f98f56ee6c890 ) I wouldn’t trust his database security either.

You changed the punctuation mark in the first quote to be a period rather than the comma that I provided. The first two quotes are one in the same statement, e.g.

I clearly stated that it’s perfectly acceptable (admirable in your case of wanting to be able to notify users of new versions) to require a registration:

I’m more concerned about my own login credentials. Data being transmitted over https is industry standard at this point. So much so that in an upcoming version of Firefox, connections over non encrypted connections will not be allowed.

I do not lack understanding, it is just that my understanding is different based on decades of previous experience in other languages. I tend to follow a moderate and reasonable interpretation of programming principles while others tend to be more extreme. As is typical of all extremists they cannot tolerate opinions which are different from their own but that will NOT prevent me from expressing my opinion.

You are missing an important point. Following academic theories to the Nth degree without any regard to what you are actually producing simply does not cut it in the real world. It is a question of balance, of making trade-offs. The endless pursuit of theoretical perfection has to be balanced with commercial reality as theoretical perfection can never be reached. At some point you have to ship working code to the customer and it is HIS opinion, not the opinion of other developers which really counts. The proof of the pudding is in the eating, so you are wasting your time if all the work you put into your recipe results in something which is inedible.

OH YES HE DOES! If you read his article at http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html you will see this statement:

He is quite clearly using the word “concerns” in an article about “responsibilities”.

Laravel’s objects by default save to the database. That article explains how to add custom behavior. The CRUD screens are custom behavior. Again, whether you consider RADicore a “more advanced framework” because it supplies screens for writing custom behavior does not change the meaning of the word framework.

You are welcome to prefer your approach. You are not welcome to change the meaning of words.

1 Like

I am following my interpretation of SRP which is more moderate than yours. As a pragmatist I only follow those rules that make sense to me and which actually produce benefits. All the others I ignore.

“I don’t understand the difference between a leopard and a cheetah therefore they are exactly the same thing”

That does not say they are the same thing, only that they are related concepts. As you’ve said yourself.

1 + 2 + 3 == 1 in this odd worldview of yours.

$SoC = 1;
$coupling = 2;
$cohesion = 4;

$SRP = $SoC + $coupling + $cohesion;

var_dump($SRP === $SoC);

Unless you can make that evaluate to true without making any of the values zero or negative (ie, meaningless or not actually included) or changing the definition of SRP so it doesn’t include all 3 concepts, or changing the operator to something other than equality (You are saying they are EXACTLY THE SAME), then your point is null and void.

I’m going to keep posting this code for you to fix until you do it or give up.

This argument still boils down to “I don’t understand the difference therefore they are the same”. Pointing out your own ignorance is not evidence to back up your claim. All it proves is that you don’t understand the concepts.

Then your argument is moot. The fact that you are a pragmatist and “don’t need to follow the rules” is irrelevant if you’re choosing to follow the rules

If you bothered to read that article you would see that it talks about the overuse of inheritance causing problems. This topic is discussed further in http://www.visbox.com/prajlich/T/node14.html which states the following:

In the first place I do not have any complex class hierarchies so I do not have the problem.

In the second place all of my Model classes inherit from a single abstract class.

So not only do I not have the problem I am already implementing the solution.

Yeah so you ignored the article I posted and cherry picked a sentence from a different one. This tactic isn’t worthy of a response, I’ll just provide a quote from the article I linked to:

. Inheritance is a very
strong relationship. Derivatives are inextricably bound to their base classes.
For example, the outOfOrder and swap functions of IntBubbleSorter are
exactly what are needed for other kinds of sort algorithms. And yet, there is no way to
reuse outOfOrder and swap in those other sort algorithms. By inheriting
BubbleSorter we have doomed IntBubbleSorter to forever be bound to
BubbleSorter. The STRATEGY pattern provides another option.

Inheritance heavily limits flexibility due to tight coupling. You still don’t understand coupling so I don’t expect you to understand this either.