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

[tony_marston404]

@s_molinari

You missed the point by a mile. It isn’t about what people like. It is about you parading around like you are the king of PHP and your framework is the golden crown jewel of frameworks.

I have never claimed to be the king of PHP and I have never claimed that Radicore is the crown jewel of frameworks. All I have ever claimed is that my methods, which are different from yours, are still capable of producing functioning and marketable software, which means that YOUR methods are not the only methods with those capabilities. You do not like the idea that I can be different yet just as good.

[TomB]

@tony_marston404

I have never claimed to be the king of PHP and I have never claimed that Radicore is the crown jewel of frameworks. All I have ever claimed is that my methods, which are different from yours, are still capable of producing functioning and marketable software, which means that YOUR methods are not the only methods with those capabilities. You do not like the idea that I can be different yet just as good.

No you haven’t. You have claimed that:

• Inheritance does not produce coupling
• DI is EVIL
• Singletons don’t produce tight coupling
• SRP is the same as SoC
• A 9000 line class follows SRP

This is the problem tony. You spread erroneous information and you pretend to be an authority.

“Just as good” is subjective. Unless you’re going to provide a metric you’re using to measure “good”, it’s a pointless statement to make. The problem is, where you claim it is “just as good” based on known metrics, like SRP, where your code is measurably worse… so you have to start trying to redefine SRP so that you can call your code “good”.

[tony_marston404]

@TomB

Good so we finally agree. SRP and SoC are not the same thing and your monster class breaks them both. Excellent.

No, we do NOT agree. SRP and SoC are NOT different concepts, they are the same concept being described using different words.

[tony_marston404]

@TomB

A reasonable person knows where to draw the line

By what metric are you quantifying “reasonable”?

Only an unreasonable person would want me to explain what “reasonable” meant.

[cpradio]

@tony_marston404

How so?

The fire is applying Radiant heat and Induction, well, is Induction. The way it heats the vessel containing the water to bring it to a boil greatly differs. The outcome is boiling water, sure, but the two are entirely different in their approach. Which is exactly what everyone is trying to inform you with SRP versus SoC.

[TomB]

@tony_marston404

No, we do NOT agree. SRP and SoC are NOT different concepts, they are the same concept being described using different words.

Tony you already said they’re different here:

Uncle Bob is saying that SRP has replaced SoC because SRP now includes the ideas of Coupling and Cohesion which SoC did not. They are NOT different concepts which will produce different results.

SRP == SoC + Coupling + Cohesion

Your words. Unless Coupling and Cohesion are meaningless (they’re not), then SRP != SoC by your own definition.

To say that now SRP == SoC is like saying

Cake == Butter + Flour + Eggs

Therefore Cake == Butter

[TomB]

@tony_marston404

Only an unreasonable person would want me to explain what “reasonable” meant.

It’s a weasel word ( https://en.wikipedia.org/wiki/Weasel_word ) so yes, it is important for you to explain what you mean. Such sweeping statements are meaningless: “Only an insane person would claim not to be insane”… it’s tripe.

[tony_marston404]

@TomB

tony_marston404:
In other words Separation of Concerns has been given more substance and rebranded as Single Responsibility Principle.

Given more substance: So they are not the same. Thank you.

They are the same concept. Soc has been superseded by SRP as it now includes “cohesion” and “coupling”. It is simply a better definition of the same concept.

@TomB

By your own definition they can produce different results because someone following SoC and not SRP doesn’t have to take coupling or cohesion into account, which will end up in a different result.

That’s a ridiculous argument. It is simply not enough to create classes at random without considering cohesion and coupling. Good design requires the creation of classes which exhibit high cohesion and low coupling. SoC did not mention cohesion and coupling because those two terms did not exist when SoC was devised. SRP took care of that by combining those three terms into a single principle. Thus SRP is used INSTEAD OF SoC, not AS WELL AS.

[TomB]

@tony_marston404

They are the same concept. Soc has been superseded by SRP as it now includes “cohesion” and “coupling”. It is simply a better definition of the same concept.

Which means they are different by your own definition.

SRP == SoC + Coupling + Cohesion

Your words. Unless Coupling and Cohesion are meaningless (they’re not), then SRP != SoC by your own definition.

To say that now SRP == SoC is like saying

Cake == Butter + Flour + Eggs

Therefore Cake == Butter because the cake has replaced the butter

[tony_marston404]

@cpradio

tony_marston404:
I have already answered that in post #240

I believe you said it was implied, and therefore, it isn’t specifically stated and thus at the interpretation that one chooses to accept of said content?

If you bothered reading the other posts in this discussion you will se plenty of places where inferences are made all over the place such as “the article switches between using concern and responsibility, but as it does not expressly say that they are the same I can only conclude that they are different”.

[TomB]

@tony_marston404

That’s a ridiculous argument. It is simply not enough to create classes at random without considering cohesion and coupling. Good design requires the creation of classes which exhibit high cohesion and low coupling. SoC did not mention cohesion and coupling because those two terms did not exist when SoC was devised. SRP took care of that by combining those three terms into a single principle. Thus SRP is used INSTEAD OF SoC, not AS WELL AS.

Which further proves my point. If SRP is used instead of SoC then they are different concepts otherwise nothing would have needed to be replaced and we’d still be using SoC.

By your own definition they are different, have different meanings and are applied in different ways.

SRP took care of that by combining those three terms into a single principle.

And if SoC and SRP were the same, this would not have been necessary in the first place because we’d already be using SRP, just calling it SoC.

Tony Marston: “I combined a banana an apple and a pear. Some people call it a fruit salad but I call it a banana”

Honestly tony the logic here is ridiculous: Combine 3 things together and it’s identical to one of the original things. This is some sort of homeopathic programming (and we all know how well that works)

[tony_marston404]

@TomB

Your interpretation is wrong. It stretches the definitions of the concepts beyond recognition. This is a result of retrospectively applying the concepts to 10+ year old code and trying your hardest to make it fit. The only way that’s possible is by redefining the concepts.

It is not wrong, it is different. I am not stretching the definition, I am sticking within the bounds of what it actually says and not going beyond that. I am applying a reasonable and moderate interpretation. It is YOU who are trying to take it to extremes.

@TomB

Why is this data which is used for display purposes only, e.g.

    var $no_csv_header = false;         // turns off creation of header row in CSV output file
    var $no_display_count = false;      // yes/no switch to display count after multiple inserts or updates

These variables clearly belong in the view, you’ve also broken SoC. Congrats

I disagree. Those are merely pieces of data which are passed to the View object at runtime in order to alter what the View object actually does. It is a rule which is set within the Model class but passed to the View object in order to be executed.

[TomB]

@tony_marston404

I disagree. Those are merely pieces of data which are passed to the View object at runtime in order to alter what the View object actually does. It is a rule which is set within the Model class but passed to the View object in order to be executed.

And if you need different information about the CSV e.g. maybe you want to pivot the table 90 degrees, you need another variable in the model. +1 reason to change.

These are display variables and belong in the view. Broken SRP, broken SoC. Well done.

[tony_marston404]

@TomB

tony_marston404:
I disagree. Splitting a class into two reduces cohesion and increases coupling.

It reduces cohesion and it reduces coupling

I disagree. If you construct more classes to achieve a result then you have to instantiate and pass control to more objects to achieve that result. Coupling is directly related to number of method calls, so the more calls you have the more coupling you have.

@TomB

Because both methods are in the same class they are tightly coupled.

I disagree. Methods in the same class are not coupled as there is no call from one object to another. Methods in the same class contribute to cohesion, not coupling.

[tony_marston404]

@TomB

tony_marston404:
No it does not as each script it creates and each record it adds to the database is unique, so how can it possibly violate the DRY principle?

Just because you’ve automated the process doesn’t mean it’s not repeated each time… you just coded something to do it for you. My point was, this repetition of each of those steps you mentions exactly that.

According to your logic if I use the “Add Customer” transaction 100 times to add 100 different customers to my database then I have violated the DRY principle simply because I have used the same transaction 100 times. Do you now how ridiculous that sounds?

[TomB]

@tony_marston404

According to your logic if I use the “Add Customer” transaction 100 times to add 100 different customers to my database then I have violated the DRY principle simply because I have used the same transaction 100 times. Do you now how ridiculous that sounds?

If it’s generating similar code 100 times then yes, it is violating DRY. Just because you automated the repetition and didn’t have to type it out repeatedly doesn’t mean there isn’t repeated code, it’s just automatically generated repeated code.

[tony_marston404]

@TomB

Way to miss the point… I was pointing out that if we’re discussing OOP Concepts the language we are using makes no difference.

You are seriously missing the point. This is a PHP group, so all the code samples should be for PHP as those who don’t use the other language will not have the faintest idea what you are talking about… It’s called common sense, dude.

[TomB]

@tony_marston404

You are seriously missing the point. This is a PHP group, so all the code samples should be for PHP as those who don’t use the other language will not have the faintest idea what you are talking about… It’s called common sense, dude.

If you don’t have the faintest idea what a TextField and Button are you don’t belong in any discussion about programming. I didn’t supply any code… just class names. Pretend it’s PHP if you like.

[tony_marston404]

@mAAdhaTTah

A very small amount of code is required to be written to hand control off to the framework.

I disagree with “is required to be written by hand” as although it is required, with the Radicore framework it is generated and not written by hand.

[tony_marston404]

@TomB

It’s called an analogy. It’s the exact same argument you are making applied to a different topic. You only want me to stop because it’s proving that you don’t have a clue what you’re talking about.

Incorrect. I simply refuse to waste time by disproving your analogy. Please stick to the ACTUAL topic and don’t switch the discussion to something else entirely.