Uncle Bob on the Single Responsibility Principle

Single Responsibility Principle.md

(from SOLID Principles with Uncle Bob - Robert C. Martin - http://www.hanselminutes.com/145/solid-principles-with-uncle-bob-robert-c-martin)

Single Responsibility Principle, what does it mean? It means that a software module should have one reason to change, then that's what I call a responsibility, a reason to change.

So for example, take a payroll application, if there's an employee class in that payroll application, you could imagine that it might have methods for calculate pay or perhaps another method for print a report, perhaps another method in the employee object for save me to the database, and what's unfortunate about these three methods existing in the same class is that they have all three completely different reasons to change. The payroll, the calculate pay will change if the accountants decides on a new way of calculating pay. The report generator will change if the people who consume the reports want the format of the reports to change. The save function will change if the DBA's decide that we needto change the database's schema. That means that this one class has three different reasons to change and there are probably many other classes that depend upon it and so as it changes those depending classes also suffer through change, they'll be effective or impacted by those changes.

So the Responsibility Principle simply says, "Find one reason to change and take everything else out of the class." So that you separate the things that change for different reasons, you group together the things to change for the same reasons. This is somewhat out of the norm for object oriented design, early object oriented design principles had as grouping together functions that operated on the same data structures so that the methods of a class would all manipulate the same variables of that class, but if those methods change for different reasons then they really belong in separate classes.

Do you have such kind of description of all other solid principles, like open/closed principle?.

Yes I do. I believe that instead of "single reason to change" we should say "a single goal to fulfill". In a goal-driven architecture each goal and its sub-goals should be assigned to a separate module.

@gopalkumar315 sorry to be soooo late in my response.
You can find a nice description of the SOLD principle in the same podcast linked at the beginning of the snippet: https://www.hanselminutes.com/145/solid-principles-with-uncle-bob-robert-c-martin
There's also a transcript in the very same page.

I also found a great explanation of the SOLID principles in UncleBob's book "Clean Architecture", chapters 7-11.
See my mindmap of those chapters: https://my.mindnode.com/n4xFysT4pTDCjN1XL8pGWkzZmPhu7YexTcx96t6x#-14.3,188.5,2

hi @parsa-git, after reading "Clean Architecture" I think I understood better the SRP: its focus is not so much on the "single responsibility" but on the "single reason to change / same frequency of change". Again, see chapter 7 of "Clean Architecture".
It's the same thing that said e.g. Kent Beck in Implementation Patterns, in the section "Rate of Change", p.17:

A final principle is to put logic or data that changes at the same rate together and separate logic or data that changes at different rates. These rates of change are a form of temporal symmetry.