[SideburnsOfDoom]

> What counts as a "responsibility", for instance. Where I see one responsibility some people see two and vice versa.

The Single Responsibility Principle is not a rigorously defined Scientific law, where the "responsibility count" can be exactly measured and minimised.

It is a subjective design guideline, with elements of experience, of context and of "I know it when I see it".

This does _not_ make it useless. It is still very useful indeed. But you do have to understand that disagreements over it are not always about "who is objectively right" but "which style makes the most sense in context".

[pydry]

shrug I think every time I've ever seen a disagreement about code quality it's boiled down to both developers thinking "I know it when I see it" about their separate approach.

If a set of principles lets them both think they're both correct and the other one is wrong, what exactly is the point of those principles?

This isn't just a coding thing. It's also, say, why society follows a body of laws rather than something like the 10 commandments.

[ehnto]

There are so many instances in code where two options are just as good as eachother by some negligible margin. The actual problem that needs solving is figuring out how to compromise and collaborate.

That's why, if I am on a team project, I much prefer working in opinionated frameworks with strong idioms. It actually doesn't matter if I think I could do it better, the framework has chosen a different way and that is fine. We all have to do it that way, and we can all compromise and collaborate. No one bickers about best, and we can get real work done.

Different when it is a project of my own, but if it requires teamwork you need a framework of collaboration as much as a framework of code.

[pydry]

>There are so many instances in code where two options are just as good as eachother by some negligible margin.

This is my other beef with SOLID: no trade offs.

I'd even extend your point to say that there are many times when code is not ideal but fixing it isn't worthwhile.

It would be nice to have a set of principles which recognized costs rather than promoting a vague, idealized standard for developers to fight over.

[d110af5ccf]

> lets them both think they're both correct and the other one is wrong, what exactly is the point of those principles

Guidelines can be useful even when subjective. Vitriolic disputes over whose (subjective) view is "correct" is an example of toxic behavior, not a problem with the guidelines being used to justify such behavior.

What would you think of someone who loudly insisted (without humor) that putting pineapple on pizza was wrong as a matter of principle? Is such expression in any way useful?

[raverbashing]

Here's the problem:

Some developers will say a (data structure) Controller is a class obeying the SRP

Some others will say the class can manage itself and not need a controller, so M and C can be one thing.

Some other will argue that it's better to make 2 controllers, one for complicated thing 1 and another for complicated thing 2, all based on the same Model.

[d110af5ccf]

That's not a problem, it just means the set of design tradeoffs to consider when solving the problem is nontrivial.

The principle draws focus to certain (arguably important) design aspects. Multiple possible approaches are identified. Various concerns are raised in response. A good solution needs to balance these concerns against one another in context.

The principle is just one of many cognitive tools to employ when thinking about the problem.