When talking about patterns, almost everyone can name the SOLID pattern (Single Responsability, Open/Close, Liskov Substitution, Interface Segregation and Dependency Inversion). The Single Reponsibility is one of the most important principle for clean code but it’s also very important for clean architecture. Let’s explore this
The SRP states that a class should have one, and only one, reason to change. In other words, a class should encapsulate a single responsibility or functionality. Let’s break down what this means:
- Reason to Change: When we say “reason to change,” we refer to any modification that might occur in the future. It could be due to a change in business requirements, a bug fix, or an enhancement. Each reason for change corresponds to a specific responsibility.
- Class Independence: By adhering to the SRP, we ensure that each class focuses on a distinct aspect of the system. This independence has several benefits:
- Maintainability: When a class has a single responsibility, it becomes easier to understand, modify, and maintain. Changes related to that responsibility won’t affect other parts of the system.
- Testability: Isolating responsibilities allows us to write focused unit tests. We can verify each responsibility independently.
- Flexibility: If a requirement changes, we only need to modify the relevant class. Other classes remain unaffected.
Example
Imagine a module responsible for compiling and printing a report. According to the SRP:
- If the content of the report changes (e.g., new fields, formatting), it’s a valid reason to modify the module.
- However, if the report’s printing mechanism changes (e.g., switching from PDF to HTML), that’s a separate responsibility.
By adhering to the SRP, we’d separate these responsibilities into distinct classes or modules. This way, changes related to content or printing won’t intertwine.
Understanding the SRP
This is somehow a bit remote from the common understanding of the SRP (A class should have only one responsbility, or that a class should do one and only one thing). The reason of change as being the question to ask whether the class follows the SRP is a very interesting take on the pattern.
If we apply this to a library, we can see that if the library has multiple reasons to change, then it might be a good idea to separate it into smaller libraries.
Maintenability
The idea behind all this remains the maintenability and ensuring that the cost of any change will remain minimal. That is often the most underestimated cost of a project. Since applications often live far longer than expected, reducing the cost of change is a must.
Having libraries that have been developed with the SRP in mind will also be much easier to migrate or rewrite when comes the inevitable time when the application needs to be updated or rewritten.
Keeping this in mind will also greatly facilitate the use of the Strangler Fig Pattern1
Conclusion
The SRP is a fundamental principle that promotes modular, maintainable, and robust software. Applying it ensures that our codebase remains adaptable and resilient to future changes.
Remember: A class should have one, and only one, reason to change.
For more in-depth exploration of Clean Architecture and other SOLID principles, I recommend reading Robert C. Martin 2.
Happy writing! 🚀