Many of you will be familiar with SOLID as it is one of the fundamental design principles in object-oriented software development. The five principles that make up SOLID are as follows:
- Single Responsibility Principle
- Open/Closed Principle
- Liskov Substitution Principle
- Interface Segregation Principle
- Dependency Principle
All of these principles are worth getting familiar with, but in this blog, we will take a quick look at the first of them.
This grouping together of the five SOLID principles was done by legendary software engineer Rober C. Martin. And when talking about the Single Responsibility Principle, we can best introduce it with the words of the man himself:
The beauty is in the simplicity of the principle as stated, but it is a lot more complicated to put into practice. However, developers who do follow this principle will be those that produce some of the very best software. While often thought of as referring to classes alone, this principle can also be implemented in software components and microservices.
Why the Single Responsibility Principle is Good
Much like the simple summary of the principle itself, the Single Responsibility Principle is one that you should try to adhere to because it makes your life easier. By following the SRP, you protect yourself against some of the side effects that can be brought about by change in the future.
The Impact of Change
The SRP tries to simplify the impact that a change of requirements will have in the future. When requirements do change, this changes the responsibilities of each class. If your class has many responsibilities, this means that more changes will be needed. And even if only one responsibility changes, you need to change the whole class.
By only giving each class one responsibility, you counter the need for multiple changes when one requirement changes in the future. Basically, by following the one class, one responsibility principle, you reduce your workload and the need for multiple unnecessary and complicated changes that could bring unwanted side effects.
Aside from helping to negate the need for unnecessary changes, the SRP brings developers another significant benefit. Classes that only have one responsibility are simply easier to explain, implement, and understand than those designed to solve everything. The consequences of this simplicity are fewer bugs, faster development, and basically a much easier life in general.
However, one big thing to be aware of here is that you must resist the urge to make everything too simple. By taking the principle too far and creating classes that only have a single function, developers will encounter many problems later on when writing code. The SRP is a great guide, but you should not always extend it to all elements of your work.
The SRP can trick people into believing it is a simple, foolproof method to implement. It certainly is not.
When working on a long-term software build, the easiest option is usually to meet new requirements by adding a method of functionality to the existing code. This is quicker than writing a new class. Unfortunately, this is where classes will gain responsibilities that will make the software more challenging to maintain later on.
An excellent way to get around this problem is to ask yourself a quick question before going ahead with any changes: What is the responsibility of this class?
Suppose the answer that comes involves you needing to give an answer that includes “and”. In that case, there’s a good chance you are going against the Single Responsibility Principle. When this happens, it makes sense to look for a better way to implement the change.
The SRP is one of the most popular design principles for a reason. It works really well when applied correctly.The problems occur when you decide to skip the principal and start to complicate classes with extra responsibilities.
By simply asking yourself “What is the responsibility of this class?” when preparing to make any changes, you can follow best practices and work in accordance with the SRP.
As long as you are careful not to take the SRP too far by creating classes with only one function, working to the Single Responsibility Principle will see you produce better work that is easier to explain and which is prone to less bugs and other issues in the future.