Hypothesis

The concept of single responsibility goes beyond merely executing a functional task within the source code.

Exploration of the Topic

In his original article, Uncle Bob attempts to explain and define what the Single Responsibility Principle (SRP) truly means. Various sources are referenced throughout the article, and terms like decomposition and module are frequently used when quoting those references. This suggests that the principle is not directly tied to writing code itself, but rather to techniques for defining and delimiting software contexts.

After defining the principle as “each software module should have one and only one reason to change,” the focus of the article seems to shift toward identifying the reason something (in this case, the software) might change. This implies that the primary motivation for delimiting a module’s context lies in understanding its reasons for change. Since the word module is used repeatedly, it may be useful to include it in further discussions to arrive at a deeper definition.

The author’s attention then turns to strategies for determining the reasons behind potential changes. It is mentioned that some people interpret “reason to change” as any modification to the software such as a refactor, a bug fix, or an update but the author (at least implicitly) rejects this interpretation. Instead, he begins to explore the concept of responsibility as it relates to reasons for change. Therefore, it seems that the Single Responsibility Principle is far from trivial, as it directly depends on these underlying reasons.

As the explanation unfolds, the author raises several questions but seems to emphasize one in particular: “Who must the design of the program respond to?” This suggests a direct relationship between software design and the entity it is accountable to. At this point, some ambiguity arises. Who exactly is this “who”? A person? A department? A business requirement?

The example provided refers to C-Level positions in a company—typically executive roles with decision making power. Initially, this example doesn’t seem straightforward, and it appears to be more related to the company’s organizational structure than to specific features, business requirements, or technical concerns.

The author then explains the responsibilities associated with each C-Level role, which suggests he is trying to draw a parallel between those responsibilities and the previously discussed concept. However, the author’s main point remains somewhat unclear.

A snippet of code is then introduced:

public class Employee {
  public Money calculatePay();
  public void save();
  public String reportHours();
}

Apparently, the example shows a single class containing quite distinct functionalities. It seems to mix persistence methods (like save) with query and financial calculation methods. Clearly, this is a case of one class containing methods that handle very different concerns.

Immediately after the example, the author explains what each method does, reinforcing the impression that they are indeed unrelated tasks. Following this, he raises questions such as: who would be fired if one of these methods were poorly specified? This introduces a sense of confusion—and even a punitive tone—to the explanation. However, it seems the author’s intention is to illustrate the idea of someone being held accountable for not fulfilling their responsibilities competently.

The term responsibility becomes especially evident in the question:
“Now, which of those C-Level executives reporting to the CEO is responsible for specifying the behavior of the calculatePay method?”

In the explanation, each method is assigned to a different C-Level executive. This suggests that each role holds responsibility over different methods and should therefore be accountable for changes to their respective specifications.

Later, the author introduces a new phrase:
“This principle is about people.”
This adds a new dimension to the analysis. It now appears that people play a central role in defining responsibilities or reasons for change.

At this point, a few key concepts emerge: responsibility, reasons for change, and people.

Further along, the author explains that the goal is to shield software modules from the complexity of the organization, ensuring that change requests originate from a group aligned with a specific functional aspect of the business. This supports the idea that “reasons for change” are essentially about isolating and grouping concepts and functionalities that respond (a term the author uses) to the same business concern.

The author then presents additional examples where a change in one aspect should not affect an unrelated aspect, as this would be perceived as odd or even frustrating by stakeholders invested in that change. This implies that changes related to one business function should not impact unrelated business functions.

Finally, the author presents a key quote:

“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”

This clearly suggests that related functionalities which change for the same reason should be grouped into the same module. In this context, change refers to a request for modifying a functional aspect of the software, typically based on a business need. Therefore, it is recommended to group business functionalities whose change requests come from the same group (or person) the module is accountable to that is, the corresponding business function.

The article concludes by connecting all these ideas to the well-known concepts of cohesion and coupling. The author states that the ultimate goal is to increase cohesion by grouping related business functionalities together and reduce coupling, meaning separating unrelated business concerns that are the responsibility of different people or teams with distinct objectives.

Sources of information

Uncle Bob Original Article

Emerging questions

• What is a module within the context of this study?
• Do we know enough about cohesion and coupling?

Key Takeaways

• The Single Responsibility Principle is not solely about technical concerns, but rather about the relationships between functional business aspects and how those aspects are modeled to remain isolated from organizational complexity.

• One way to understand or define the reason for change is by identifying who the functional business aspect responds to, or who is responsible for it.

• A change in one functional business aspect should not affect another unrelated aspect doing so can lead to a loss of trust from those requesting the change.

• The principle is more closely tied to social, organizational, and business aspects than to the technical side of software alone.

Future Directions

I intend to explore the other aspects in greater depth. It’s likely that the remaining components of the acronym will also be the subject of a more thorough analysis.