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

A word does not change its meaning simply because it moves from the singular to the plural.

I don’t care what you say, if an article repeatedly switches between two terms when discussing the same concept then those two terms have EXACTLY the same meaning unless the article EXPRESSLY says otherwise. It doesn’t, so they aren’t.

I’m aware of that. Just making a point. :smile: (I have been reading everything posted here since day 1 – sometimes skimming and then reading it fully to ensure I read what I thought I read)

It does not break my interpretation of the rules.

Each Model class is responsible for the business rules associated with a single database table, therefore each Model class has a single responsibility.

It does not break my interpretation of SRP.

No Model class contains any code which constructs any HTML, PDF or CSV output as that is handled in totally separate classes. It does, however, contain meta-data which is passed to the relevant View object so that it can complete its task. Meta-data is not logic, so I have not broken either SRP or SoC.

If you do not understand the difference between meta-data and logic they how can you possibly call yourself a competent programmer? Data and logic are not the same thing.

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.

Your code contains the following:


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

If you want to support a different format, e.g. xml, json or YAML you have to adjust this class accordingly. That is one reason to change. If you want to change the query that is generated you need to alter this class, that’s two of many reasons to change.

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 :slight_smile:

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

Cohesion is a measure of the strength of association of the elements inside a module. A highly cohesive module is a collection of statements and data items that should be treated as a whole because they are so closely related. Any attempt to divide them would only result in increased coupling and decreased readability.

Coupling is the degree of interaction between two modules.

A class which contains methods which are closely related is therefore highly cohesive, and to split that class would reduce cohesion.

By creating more classes you also create more coupling between those classes as you therefore have to pass control from one object to another more often.

I already answered this is post #251

It reduces cohesion and it reduces coupling. Given the following:

function X($foo) {
$foo->findUser(1234);
echp $foo->render();
}

Because both methods are in the same class they are tightly coupled. Instead, by reducing coupling (e.g. applying SRP):

function X($foo, $renderer) {
$foo->findUser(1234);
echo $renderer->render($foo);
}

The renderer is decoupled from the data meaning different renderers can be used with the same data. A primitive example but it applies anywhere you have multiple method calls to the same object. Sometimes that coupling is warranted (e.g. setters and getters), often it’s not.

1 Like

I would qualify that statement by saying Within that set of rules which I wish to follow. There are too many different interpretations of the rules out there and it is physically impossible to implement them all in a single piece of code. So I do what every sensible programmer does - I follow the rules that work in my current situation and ignore the rules that don’t.

“I’m avoiding the question”

You provided a definition which could be applied to a version of that class with all the methods stripped out. If you can take a method out of the class and the class still fulfils its responsibility then putting the method in the class violates SRP.

Your definition must clearly describe exactly what the class does. If I can remove any of the methods or variables and it can still meet that definition then the definition isn’t clear enough.

that should be my interpretation of best practices as there is no single interpretation that is universally accepted by all programmers, and there never will be.

I am not trying to redefine SRP and Soc. It was not me who brought up the idea that they mean different things (which they don’t).

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?

No, you’re wrong again. You are the only person arguing about the definitions of these things. There is plenty of discussion about how they can be best applied but that’s another issue entirely.

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.

PHP most certainly IS an object oriented language according to the definition created by Alan Kay (who invented the term) and Bjarne Stroustrup (who designed and implemented the C++ programming language).

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

They are NOT the same. They are different languages which achieve similar results by different means. Code that will work in one language will not work in the other.

You do not prove to me that they are different concepts, just the same concept described with different words.

How so?

You did not answer where it says code must be generated by the framework. And your interpretation of “inversion of control” still remains incorrect. A very small amount of code is required to be written to hand control off to the framework. It’s little more than:

$app>boot();```

All the additional code you referenced in that article is called _by_ the framework, after control has been passed to it.

Will you stop going off at a tangent and bringing in ridiculous arguments as it is doing nothing to enhance your credibility.

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.

BINGO! This is exactly what cpradio is saying. Let’s replace PHP and Java with SRP and SOC and you get:

They are NOT the same. They are different concepts which achieve similar results by different means.