The Single Responsibility Principle (SRP) is one of the SOLID Principles in Object-Oriented Programming that was introduced by Robert C. Martin. This principle states: "a class or module should have only one reason to change". It is applicable to various software components, including modules, classes, and methods.
SRP aims to encapsulate objects that share a single common responsibility. Such elements are highly-cohesive as they provide a unified way of performing a single task. Additionally, SPR is related to the term of loose-coupling, which divides responsibilities among separate components.
In his book Clean Code, Robert C. Martin emphasized:
"We want our systems to be composed of many small classes, not a few larger ones. Each small class encapsulates a single responsibility, has a single reason to change, and collaborates with a few others to achieve the desired system behaviour."
SRP has numerous applications:
Software architectural styles: MVC, Clean Architecture, DDD, Microservices and other paradigms are divided into layers to isolate responsibilities.
Web Services: Separate modules to handle authentication, logging, persistence, validations, etc.
Lower-Level Design: Classes, methods and properties are split into separate components based on how they can achieve a single task altogether.
External integrations: "On the lowest level, this can be an integration between modules within the application, such as putting a message into a queue which is processed by another subsystem. Then, there are integrations with the system, such as logging or checking the system time" Single Responsibility Principle Unpacked (reflectoring.io)
SRP is applicable to various software systems, including finance (transactions, reports), e-commerce (products, payments), mobile and web (user interfaces, APIs), and many more.
The Single Responsibility Principle helps us improve code quality and readability through a clear separation of concerns throughout the system. It doesn't mean we have to create excessive abstractions in our codebase just for the sake of SRP. It aims to group things that change for the same reasons and isolate elements that change for different motives.
What are the benefits of SRP:
Separation of concerns: By dividing the application into distinct sections, the code will be more structured, modular, and well-organised.
Reusability: Modules, classes and methods can be shared across different contexts as they offer well-defined functionalities and are independent of other components.
Maintainability: Components with a single responsibility are easier to understand, modify, extend and are less likely to introduce bugs.
Testability: Focused and isolated modules are easier to test and debug.
However, there are some drawbacks:
Complexity: More classes with a single responsibility imply more code and can be challenging for navigation and coordination between components.
Overabstraction: SRP misunderstanding can lead to uncontrolled abstractions. It's essential to find a balance between single responsibilities and common objects.
Performance overhead: Additional method calls and component interactions when delegating single responsibilities can be considered in performance-critical systems.
Check out my video:
Comments