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

Sorry, that’s not true. One is a refined version of the other, to say they are the same thing is a fallacy of composition ( https://en.wikipedia.org/wiki/Fallacy_of_composition )

And lets be clear, tony is arguing that they are “EXACTLY THE SAME”. This is completely nonsensical when you actually look at the meanings behind them. Tony didn’t say “They are similar” or “they are related” or “one is a refinement of the other” his argument is “They are exactly the same”. If you look from a mile high “all cars are the same”. Of course on a car message board we would discuss in detail the differences between a bugatti and a mazerati. On a programming forum we should discuss the differences between programming concepts.

You are the only one who is using perverse logic to state that coupling and cohesion have no meaning, so I am not going to join in with your perversity.

Avoiding the question again, eh?

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

Answer this please:

and this:

Stop avoiding the question because you’ve been proved wrong. Are SRP and SoC “EXACTLY THE SAME THING” or are they different?

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.

By applying the same concept under different labels you are not actually applying different concepts.

They are using different words to describe the same concept. The WORDING is different but the CONCEPTS are the same. This is possible in the English language, or didn’t you know that?

YOU have stated they are different concepts.

You have said that

SoC does not include coupling or cohesion

SRP is SoC +Coupling + Cohesion.

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

That’s why I’m talking about semantics and “letter of the law”. It’s similar to talking about the Ford Shelby GT350 and a base model Ford Mustang. Technically they are different cars as the trim levels, motors, etc are different. But from a layman’s term, they are still Mustangs.

In only ONE of the many quotes I’ve seen you make did he say they were EXACTLY the same. Otherwise, he just said they were the same (which in layman’s term, they essentially are).

I’m just saying let’s not lose the forest for the trees. The basic concept is if people follow EITHER SoC or SRP, they’re heading down the right track. If they follow SRP, it’s better because the more specific it is, the better it is in the long run.

Let’s take a step back then, Tony is using the idea that SoC is identical to SRP in order to say that his 9000 line class follows SRP ( http://pastebin.com/m76ZAUZc ) would you say he’s going down the right track?

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.

Read what I wrote! They use different words to describe the same concept. This means that the concept is the same, but that the words used to describe that concept are different. The results of applying either description of that concept will be the same, so the two descriptions have the same meaning.

How can two different definitions describe the same concept? The results are not the same. If you don’t follow SRP you get 9000 line monster classes, if you follow SRP you get more, smaller classes.

Please explain how a definition that includes SoC and other things, is identical to SoC on its own.

Yes, the two definitions describe the same concept but in different words.

I do not think that a sensible person would come to the same conclusion.

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.

But not SoC and SRP. No programmer I know would use SoC to achieve one result and then follow up with SRP to achieve a different result.

It’s called refactoring. It’s quite popular, you should look it up some time.

But they are the same and produce the same result? So if I use one, surely, I’m using the other? :smile:

In all seriousness, why not? Why wouldn’t I have used SoC then included cohesion and coupling thus meeting the requirements of SRP?

1 Like

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.

First off, let’s have a little perspective - there’s really about 7,000 lines, not 9,000. There are almost 1,700 lines of comments (something that most developers - even good ones - really suck at but is critical for anyone that follows needs), probably more than 300 blank lines for readability sake, and 50-100 lines of commented out code (not needed if any sort of source control is used, but unfortunately common practice in every shop I’ve ever worked at. The class could do with a review/rewrite because it seems like it does too much, and can definitely be simplified (I found 2-3 blocks of code which could be combined/refined).

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?

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