The Single Responsibility Principle (SRP) ensures code coherence by preventing a software component from performing multiple tasks or functions and its states that
Each module should do exactly only one thing, and solve only one problem.
Robert C. Martin
A software module is a group of lines of code that are organized in a form of a class, method, package, microservice, or package. Making the module focus on only one task to achieve makes software easier to test and maintain. A module should have only one reason to be modified. It is not desirable to modify the same module for different reasons or requirements. This would indicate poor architecture and a violation of the SRP principle.
Let’s imagine a class that performs two features. If the business team requests a change in feature one, any client uses feature two will have to test its code and use the new version of the mentioned class, however that client was not using the changed feature.
SRP origin is separation of concerns.
Single responsibility principle is based on a well known scientific rule that is called, separation of concerns. Separation of concerns as a term was mentioned and explained Dijkstra on his publication “The role of scientific thought” on the year 1974. When we study a subject we should not study multiple variables at the same time. We study one variable and assume other variables are constant, then we study other variable separately and again assume other variables are constant till we have a complete idea about all the variable on the studied system. Another example when we solve two equations in 2 variables, we do not solve the 2 variables at the same time, we first try to remove one of the variables from one equation, once we get the value of the first variable we can substitute its value in the second equation to get the value of the second variable. The below text being quoted directly from Dijkstra explaining the separation of concerns concept.
“Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one’s subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained —on the contrary!— by tackling these various aspects simultaneously. It is what I sometimes have called “the separation of concerns”
