Single Responsibility Principle
Tags: #🌲evergreen
Links: Encapsulation
Every Software Unit should encapsulate and have responsibility over a single part of the system that overlaps as little as possible. [1]
In other words, you should write the system gathering things that change for the same reasons and separating those things that change for different reasons (see Cohesion and Coupling).
One intention of this principle is to improve Organizational Scalability by allowing developers to work on different parts of the system without affecting each others work.
It also makes it easier to reason about a module by reducing Team Cognitive Load by helping to abstract away unecessary details.
Having separate responsibilities also leads to a more robust code base. Example: a module that compiles a report and prints it. Without applying SRP any change to the compilation responsibility would affect the unrelated printing responsibility.
Separation of Concerns
Separation of Concerns is considered the same as SRP here [2]. It originally states that each class should have only one reason to change (or responsibility). Example: an invoice class should not have to print itself.