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

[tony_marston404]

@TomB

Have you learnt nothing about authority?

The only thing I have learned from you is to ignore everything you say.

[TomB]

@tony_marston404

So you are saying that any application which has a user transaction which can be used more than once violates the DRY principle? Do you know how ridiculous that sounds?

I’m saying that the system can be better designed to have a better workflow and remove needless repetitive tasks.

[TomB]

@tony_marston404

The only thing I have learned from you is to ignore everything you say.

Then please stop arguing when you’re clearly in the wrong… Either answer the questions I ask or stop going off on tangents like this.

[Mittineague]

@DaveMaxwell

could do with a review/rewrite

Excellent thought,

It’s quite evident that some members take great interest in Tony’s code

@tony_marston404

Have you ever thought of putting your code up so you could review contributed pull requests?

[tony_marston404]

@TomB

Please answer the question: How the hell can two terms with different definitions mean the same thing?

Different words, same meaning. This is possible in the English language, or didn’t you now that?

[TomB]

@tony_marston404

No it is NOT display logic. Display logic is the CODE which is used to transform data into a specific format for display. The Model passes data to the View, and the View transforms it for output. Some of the data which can be passed to the View could be meta-data which affects the processing in the View, but it is still DATA and not CODE.

How exactly is this:

        if (preg_match('/^(csv|pdf)/i', strtolower($GLOBALS['mode']))) {

Data and not code? It’s display logic (What is the output mode?) and it’s in your model. If you add a new output mode, e.g. XML, you need to change this class.

[TomB]

@tony_marston404

Different words, same meaning. This is possible in the English language, or didn’t you now that?

But this is, by your own definition, different words with DIFFERENT MEANINGS

Meaning 1:
Separation of Concerns: Does not include coupling or cohesion

Meaning 2:
Single Responsibility Principle: Everything from SoC + coupling + cohesion

Stop trying to backtrack your way out. There are two different labels for two different concepts and you’re calling them “the same”. They’re not, by your own definition.

You still didn’t answer my question from before:

How can:

Cake = Butter + Flour + Eggs

Mean that Cake and Butter are “EXACTLY THE SAME”. That is what you’re saying here, you’re taking one of the constituent parts of SRP (SoC) and saying it’s the same as the whole.

[tony_marston404]

@DaveMaxwell

Can we PLEASE get over talking semantics and “Letter of the Law”? From a high level, they are the same concept. SRP might have a slightly more narrow definition of successful compliance as it’s essentially SoC 2.0, but from a basic, mile high perspective, they are the same,

You shouldn’t agree with anything I say in this forum otherwise the “paradigm police” will be at your throat like rats up a drainpipe. I am considered to be a heretic and a pariah, so if you agree with me on anything at all you are likely to be tarred with the same brush.

[tony_marston404]

@TomB

How then, are these concepts the same, if they describe different things?

Because Uncle Bob says so in his article http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html. He is clearly describing the SAME concept but using DIFFERENT terminology.

[TomB]

@tony_marston404

Because Uncle Bob says so in his article http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html. He is clearly describing the SAME concept but using DIFFERENT terminology.

You’re going round in circles here. That article states that SRP is SoC AND Coupling AND Cohesion, not that they are THE SAME CONCEPT. This is a different concept because it describes something different!

How can:

Cake = Butter + Flour + Eggs

Mean that Cake and Butter are “EXACTLY THE SAME”. That is what you’re saying here, you’re taking one of the constituent parts of SRP (SoC) and saying it’s the same as the whole.

[tony_marston404]

@mAAdhaTTah

tony_marston404:
Not unless they comply with the Wikipedia definition!

They do. That’s my point. You write a few lines and hand execution off to the framework. That’s inversion of control. That’s what they do.

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

[TomB]

You still haven’t answered my question from before:

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.

[tony_marston404]

@TomB

Explain to me, in detail, how a definition that includes SoC and includes Coupling and Cohesion can mean the exact same thing as SoC on its own.

As DaveMaxwell said in post #366, SRP can be treated as SoC version 2.0 as it is a much later version of SoC but uses different terminology to describe the same concept. The WORDING may be different but the CONCEPT is the same.

[TomB]

@tony_marston404

As DaveMaxwell said in post #366, SRP can be treated as SoC version 2.0 as it is a much later version of SoC but uses different terminology to describe the same concept. The WORDING may be different but the CONCEPT is the same.

That’s simply not true though is it? You have said yourself that:

SRP = SoC + Coupling + Cohesion

This is a DIFFERENT CONCEPT to SoC on its own.

I assume at this point you’ll want to redefine the word “Concept” and say “SRP isn’t a concept”

[tony_marston404]

@TomB

It has 140+ methods and around 70 variables. It clearly violates SRP.

Anybody who says that my code violates SRP simply by counting the number of methods and lines of code is not being scientific or rational. All those methods are closely aligned to the SAME responsibility which is to enable each Model class to contain the business rules for the database table which it represents.

[DaveMaxwell]

@TomB

Only 7000 lines? It has 140+ methods and around 70 variables. It clearly violates SRP.

The number of methods and variables has nothing to do with SRP. If the methods are variables work with similar needs in place, then SRP is OK. (NOTE: I’m not saying that’s the case here)

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.

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

All of these could be resolved by a periodic code review/refactor. Problem comes because code reviews don’t pay the bills.

[TomB]

@tony_marston404

Anybody who says that my code violates SRP simply by counting the number of methods and lines of code is not being scientific or rational. All those methods are closely aligned to the SAME responsibility which is to enable each Model class to contain the business rules for the database table which it represents.

I have repeatedly said that metrics like those give an overview. The lower the number of methods, the lower the chances of a SRP Violation. At 100+ methods you’re up to about 99% probability of a SRP violation.

SRP is reasons to change, I’ve listed these multiple times in the thread and you’ve ignored them. A couple from a quick glance at the class:

• Needing to change the class if the output method changes e.g. an XML file
• Needing to change the class if any of the business rules change
• Needing to change the class if you want to change the generated SQL statement
• Needing to change the class if you want to change the format of the getData call (which is why you have two different methods that do this, at some point you had to add the extra one)
• Needing to change the class if you change the way the delete works (You’ve already done this which is why you have 3 different delete methods)
• Needing to change the class if you want to store workflows in a different table:

if (preg_match('/^(workflow|audit)$/i', $this->dbname) OR defined('TRANSIX_NO_WORKFLOW') OR defined('RADICORE_NO_WORKFLOW')) {

• Needing to change the class if you change the way current or historical data is represented:

if ($field == 'curr_or_hist') {

Needing to change the class if you want to change the way the scroll array is stored:

function clearScrollArray ()
    // initialise the internal $scrollarray.
    {
        $this->scrollarray = array();
 
        $this->scrollindex = 0;
        $this->pageno      = 0;
        $this->numrows     = 0;
        $this->lastpage    = 0;
 
        return;
 

E.g. if you wanted to add a cursor position on a specific record.

• needing to change the class if you want to set/unset a different script var here:

                if ($this->initiated_from_controller) {
                    if (isset($GLOBALS['script_vars']['task_id_run_at_cancel'])) {
                        unset($GLOBALS['script_vars']['task_id_run_at_cancel']);
                        unset($GLOBALS['script_vars']['task_id_run_at_cancel_context']);
                    } // if

Needing to change this method:

    function convertTimeZone ($fieldarray, $fieldspec)
    // convert any datetime fields from client timezone to server timezone.
    {
        if (isset($_SESSION['display_timezone_party']) AND is_True($_SESSION['display_timezone_party'])) {
            if (!empty($fieldarray['party_timezone'])) {
                $timezone_client = $fieldarray['party_timezone'];    // timezone of data's party
            } else {
                $timezone_client = $_SESSION['timezone_client'];     // timezone of logon user
            } // if

if you want to support PHP’s inbuilt DateTime object.

I’m about 1/5th of the way down the class and I’ve found half a dozen or more “reasons to change”. It violates SRP.

@tony_marston404

If I have to enter the details of 100 customers then it is logical that I use the “Create Customer” task 100 times. How can this be a violation of the DRY principle?

You can improve the process: Get the customers to enter their own details, import the data from a CSV or elsewhere, avoid the repetition of the task.

[tony_marston404]

@TomB

I’m saying that the system can be better designed to have a better workflow and remove needless repetitive tasks.

If I have to enter the details of 100 customers then it is logical that I use the “Create Customer” task 100 times. How can this be a violation of the DRY principle?

[tony_marston404]

@Mittineague

Have you ever thought of putting your code up so you could review contributed pull requests?

My entire framework is open source under the name RADICORE and has been available for download since 2006. I shan’t post the URL in case the paradigm police accuse me of spamming!

[tony_marston404]

@TomB

tony_marston404:
Because Uncle Bob says so in his article http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html. He is clearly describing the SAME concept but using DIFFERENT terminology.

You’re going round in circles here. That article states that SRP is SoC AND Coupling AND Cohesion, not that they are THE SAME CONCEPT. This is a different concept because it describes something different!

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

Different name, same concept.