Incorrect characterization of SRP

[faisalmemon]

The article says:

We make changes to our systems to satisfy our users and stakeholders. We are responsible to them.

A module should be responsible to one, and only one, user or stakeholder.

This is what this Single Responsibility Principle is all about. Simply put, if we introduce a bug in one place, and then two different business people come to complain, we've violated the principle. It has nothing to do with the number of things we do in our module.

Cross-checking with Gemini

The principle doesn't state that a module should be responsible to a single user or stakeholder.

The Correct Interpretation of the Single Responsibility Principle

The Single Responsibility Principle (SRP) is a core tenet of software design, particularly within the context of SOLID principles. It states that a software module, which can be a class, function, or microservice, should have one, and only one, reason to change.

This "reason to change" is directly tied to a single responsibility or a single part of the program's functionality. It's about grouping related functionality and separating unrelated functionality. This makes the code easier to understand, maintain, and extend.

Cross-referencing with Wikipedia

Single responsibility principle
The single-responsibility principle (SRP) states that "there should never be more than one reason for a class to change."[6] In other words, every class should have only one responsibility.[7]

Importance
Maintainability: When classes have a single, well-defined responsibility, they're easier to understand and modify.
Testability: It's easier to write unit tests for classes with a single focus.
Flexibility: Changes to one responsibility don't affect unrelated parts of the system.[7]

Would you consider the above commentary and consider revising your document as I think your intention was to stick within the confines of the SOLID principles in this section of your document.

[zakirullin]

Hi there! I am not going to rely on an AI-generated answer. I am surprised that you've used probabilistic machine's output as a clarification to such an intricate question.

This definition was corrected by the original author itself (the one who has coined the term in the first place AFAIK). He admits that providing such a vague explanations in the past was unfortunate, and that it was widely misunderstood ever since then.

[zakirullin]

The originator of the term, expresses the principle as, "A class should have only one reason to change". Because of confusion around the word "reason", he later clarified his meaning in a blog post titled "The Single Responsibility Principle", in which he mentioned Separation of Concerns and stated that "Another wording for the Single Responsibility Principle is: Gather together the things that change for the same reasons. Separate those things that change for different reasons." In some of his talks, he also argues that the principle is, in particular, about roles or actors. For example, while they might be the same person, the role of an accountant is different from a database administrator. Hence, each module should be responsible for each role.

Even one person changed his own interpretation over time. Can you imagine how many interpretations and debates that already caused across other engineers?

The point of this chapter is not to give a ground truth definition of the term (which is not even possible since the whole thing is imagined). The point is to showcase that it doesn't make any sense to follow most of the rules widely shared in software development industry. You have to ask "whys" and dig deeper rather that just remembering some fancy vague acronyms and applying them here and there. Just because a principle is widely shared doesn't mean it has anything to do with reality.

[faisalmemon]

Thanks for the feedback, much appreciated. You've explained a subtlety I wasn't aware of but reading
https://developer.onepagecrm.com/blog/single-responsibility-and-separation-of-concerns-principles/#:~:text=Although%20all%20of%20these%20principles,and%20stakeholders'%20needs%20and%20requirements
I see where you are coming from.

As you enquired why I should reference Gemini as part of my issue report, I wanted to not use a my opinion but a probabilistic opinion because I didn't want to personally attack or criticize you in the writing.

I also quoted wikipedia because it is human generated, not automated and often used as common reference point and it also does not come from me.

However, your argument goes back to the author which is better than wikipedia which only captures the traditional characterization.

I can see from your comments you are going behind the traditional characterizations which is why you've departed from "confines of the SOLID principles" as I put in my issue report.

Since you are reaching for the deeper "why" my suggestion is to amend the text to say:

This is what this Single Responsibility Principle is really all about

(I added the word really).

Even if you chose not to that this route, I appreciate your thoughtfulness here.