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

[TomB]

@tony_marston404

This is not my personal view it is a view put forward by Robert C. Martin in his article http://blog.8thlight.com/uncle-bob/2014/05/08/SingleReponsibilityPrinciple.html where he says te following

And considering that SoC makes no attempt to include coupling or cohesion in its definition it demonstrates they are not the same thing.

[s_molinari]

@TomB

Single Goose Principle describes a singular goose. Separation of Geese describes how different geese are related: I’ll separate my 30 geese into 3 flocks. 10 can go to the field, 10 can go to the lake and I’ll sell the remaining 10. They’re not the same concept.

I got a good chuckle from this. LOL!

Scott

[tony_marston404]

@s_molinari

Great article. With SoCcam’s Razor on Tony’s monster class, we’d end up with a ton of shavings. LOL!

So what you are saying is that by applying your definition of SRP it would be like transforming a log (a cohesive unit) into a bunch of shavings (a collection of useless fragments).

Most programmers I know (at least the intelligent ones) would prefer to work with cohesive units rather than a collection of useless fragments.

[s_molinari]

@TomB

And considering that SoC makes no attempt to include coupling or cohesion in its definition it demonstrates they are not the same thing.

Did you get that Tony?

Scott

[TomB]

@tony_marston404

Most programmers I know (at least the intelligent ones) would prefer to work with cohesive units rather than a collection of useless fragments.

Not Robert C. Martin. This is from the book Clean Code:

At the same time, many developers fear that a large number of small, single-purpose
classes makes it more difficult to understand the bigger picture. They are concerned that
they must navigate from class to class in order to figure out how a larger piece of work gets
accomplished.

However, a system with many small classes has no more moving parts than a system
with a few large classes. There is just as much to learn in the system with a few large
classes. So the question is: Do you want your tools organized into toolboxes with many
small drawers each containing well-defined and well-labeled components? Or do you want
a few drawers that you just toss everything into?

Every sizable system will contain a large amount of logic and complexity. The pri-
mary goal in managing such complexity is to organize it so that a developer knows where

to look to find things and need only understand the directly affected complexity at any
given time. In contrast, a system with larger, multipurpose classes always hampers us by
insisting we wade through lots of things we don’t need to know right now.
To restate the former points for emphasis: We want our systems to be composed of
many small classes, not a few large ones. Each small class encapsulates a single responsi-
bility, has a single reason to change, and collaborates with a few others to achieve the
desired system behaviors.

Pages 139 - 140.

[s_molinari]

@tony_marston404

So what you are saying is that by applying your definition of SRP it would be like transforming a log (a cohesive unit) into a bunch of shavings (a collection of useless fragments).

Most programmers I know (at least the intelligent ones) would prefer to work with cohesive units rather than a collection of useless fragments.

Oh brother.

No, the shavings would be all the methods and properties we could shave out of your monster class and it still be fulfilling its single responsibility. Btw, what was the single responsibility again?

Of course, those shavings would have to be glued back together in other cohesive units/ classes, like making plywood.

Scott

[tony_marston404]

@TomB

And considering that SoC makes no attempt to include coupling or cohesion in its definition it demonstrates they are not the same thing.

The aim of the game is to produce software which exhibits high cohesion and low coupling. If you cannot achieve that by following SoC then you have failed.

[TomB]

@tony_marston404

The aim of the game is to produce software which exhibits high cohesion and low coupling. If you cannot achieve that by following SoC then you have failed.

Doesn’t back up your point at all. SoC and SRP are not the same thing.

I’m just going to post this again because you still ignored it:

@tony_marston404

Your question is ridiculous as it is based on the assumption that SoC and SRP are different. I keep telling you, even by pointing to articles written by other people, that they are NOT different, but you fail to acknowledge that point. SoC and SRP are the SAME, not DIFFERENT.

You have stated they are different:

@tony_marston404

Soc has been superseded by SRP as it now includes “cohesion” and “coupling”.

@tony_marston404

Uncle Bob is saying that SRP has replaced SoC because SRP now includes the ideas of Coupling and Cohesion which SoC did not.

You are saying “SRP includes something SoC does not”. How does that make them “exactly the same concept”?

This can be shown 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 operator to something other than equality (You are saying they are EXACTLY THE SAME), then your point is null and void.

if your definition of SRP is correct then you’ll be able to do the above. Otherwise your definition of SRP is wrong and your argument is lost.

That’s 9 times you’ve been unable to answer this post, 9 times you’ve proven yourself wrong.

[s_molinari]

@tony_marston404

The aim of the game is to produce software in modules or sets of responsibilities, which exhibit high cohesion and low coupling. If you cannot achieve that by following SoC then you have failed.

Corrected.

Scott

[TomB]

@tony_marston404

So what you are saying is that by applying your definition of SRP it would be like transforming a log (a cohesive unit) into a bunch of shavings (a collection of useless fragments).

Your analogy is flawed. It’s transforming a log into short planks which could be pieced together to make a chair, a crate, a barrel, a bookshelf, a spice rack, a wardrobe or a table. Your log can only ever be a log.

[tony_marston404]

@TomB

Your log can only ever be a log.

But still very useful if I want to build a log cabin.

[tony_marston404]

@TomB

tony_marston404:
The aim of the game is to produce software which exhibits high cohesion and low coupling. If you cannot achieve that by following SoC then you have failed.

Doesn’t back up your point at all. SoC and SRP are not the same thing.

OH YES THEY ARE!

[TomB]

@tony_marston404

But still very useful if I want to build a log cabin.

Not on its own. A log cabin is made up of lots of logs. In your analogy a “log cabin” is a “cohesive unit”.

[TomB]

@tony_marston404

OH YES THEY ARE!

Saying “Yes they are” in the face of opposing evidence without providing a counter claim only serves to demonstrate that you’re wrong.

[tony_marston404]

@s_molinari

tony_marston404:
The aim of the game is to produce software in modules or sets of responsibilities, which exhibit high cohesion and low coupling. If you cannot achieve that by following SoC then you have failed.

Corrected.

But the smallest unit in a modular OO system is still a class.

[TomB]

@tony_marston404

But the smallest unit in a modular OO system is still a class.

Just because a single class can be a module doesn’t mean all modules are single classes

“All sharks are fish therefore all fish are sharks”

[s_molinari]

@tony_marston404

But the smallest unit in a modular OO system is still a class.

Which should follow SRP.

Scott

[s_molinari]

@tony_marston404

OH YES THEY ARE!

They are similar, not the same. SoC deals with the higher software architecture level (in most cases). SRP deals with the class level (in all cases).

Scott

[TomB]

So hopefully you two got the email from Derek Greer of Aspiring Craftsman ( http://aspiringcraftsman.com/2008/01/03/art-of-separation-of-concerns/ ) one of the articles Tony has been referencing. There’s a few important things he said. Hopefully he won’t mind me posting excerpts from his email here:

1. Tony’s class does not follow SRP

Based upon the size of the class alone, however, I will say that I doubt that it adheres to the SRP because it’s unlikely that the behavior represented therein would all need to change for the same reason. I’ve written a few articles where I’ve discussed the SRP in more detail if you care to check them out.

2. SRP and SoC are not the same thing:

To this I would say that it’s possible for a given module to follow good Separation of Concerns in some areas while not following them in others. For example, a given module may encapsulate all the business logic of a given feature (as opposed to the display or persistence logic) while not separating different aspects of the business logic that would tend to change for different reasons (a SRP violation). In other cases a module may encapsulate all the user interface logic of a given application while not separating out the various features.

The concept of Separation of Concerns is a very general principle, so it isn’t well suited as a pass/fail measurement of software. Design principles like those represented by the SOLID acronym are far more well-distilled principles in which we can speak more objectively about whether a given module is in adherence with the principle or not

[s_molinari]

@TomB

To this I would say that it’s possible for a given module to follow good Separation of Concerns in some areas while not following them in others. For example, a given module may encapsulate all the business logic of a given feature (as opposed to the display or persistence logic) while not separating different aspects of the business logic that would tend to change for different reasons (a SRP violation).

Yep, this part says it all. You can have good SoC and still break SRP, so they simply can’t be the same.

Scott