This alludes to one of my main beefs with SOLID - the lack of a clear definition.
What counts as a "responsibility", for instance. Where I see one responsibility some people see two and vice versa.
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".
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.
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.
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.
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?
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.
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.
With any paradigm, there is often ambiguity with certain elements, because those elements should be dynamic. What SOLID aims to do is say that these main points are not something you should dedicate brain cycles towards, as they are best spent elsewhere in the design.
It's because, unless you're careful, human language is insufficiently precise by its nature for many domains.
This is why mathematicians communicate with mathematical notation, for instance. It's why lawyers use special lawyer only terms (or why interpretation of the law is an explicitly separated function).
With SOLID the lack of precision renders the whole exercise rather pointless.
You're supposed to be able to use these principles as something you can agree upon with other developers so that you have a shared understanding of what constitutes "good" code.
However, it doesn't happen. Instead we argue over what constitutes a single responsibility.
SOLID isn't the only example of this. "Agile" is actually far worse.
If your assumption is that design guidelines can have mathematical precision, then you're going to be perpetually disappointed.
> Instead we argue over what constitutes a single responsibility.
I'm sorry that you can't reach consensus. but IMHO, the false idea that there is a single, mathematically correct answer (and if people differ, therefor someone must be be Wrong, capital W) is often part of the problem, of what stops an agreement on how to move forward pragmatically being reached.
I don't think that there is a set of design guidelines that can be applied with mathematical precision, but there are a set of code "costs" (like cyclomatic complexity) which can be measured with mathematical precision.
That is to say, all other things being equal, if a pull request non-negligibly reduced cyclomatic complexity I'd be happy to claim that it increased code quality. I don't believe that this idea is false.
"Responsibility" is IMHO about intent and meaning, which as a human concept is not reducible to measurements of this kind. Cyclomatic complexity is all fine and well, but it cannot tell you if an intent is being met or not. It is silent as to meaning. It's relevant only if you can compare two pieces of code that do the same thing; it's not talking about what that thing should be.
I tend to agree with that, and the original article in general. Mr Martin's approach helped originally, but the dogma now can and should be moved on from.
For example, an Entity part of the persistence layer in the app, has the responsibility to persist the state of the Entity to the database, but the responsibility to know the information is with an object that is part of the business logic layer. The information that is stored in the Entity to be able to persist it to the DB is just a cache of the information in the Business Object, the Entity is not responsible for it, it just holds a cache. If the same object would be responsible for both holding the information and persisting it, it would have 2 responsibilities.
This might sound somewhat confusing and useless, but it isn't so. Imagine a future where computers have a form of RAM that is not volatile. There is no need for a database, in the classical sense – whatever is in RAM when the computer is powered off/rebooted will still be there when the program resumes running.