Single Responsibility Principle
A class should have only one reason to change.
SOLID is a mnemonic acronym named by Robert C. Martin used in Software Programming, It represents 5 principles of Object-Oriented Programming.
- Single Responsibility Principle (SRP)
- Open-Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
All of them are broadly used and worth knowing. But in this post, I will focus on the first one: the Single Responsibility Principle (SRP).
What is SRP?
One class should only serve one purpose, this does not imply that each class should have only one method but they should all relate directly to the responsibility of the class.
All the functions, methods, and properties should all work towards the same goal. When a class/method/property serves multiple purposes or responsibilities then it should be made into a new one.
“A class should have one, and only one, reason to change.”
or
“Each software module should have one and only one reason to change.”
How to recognize code smell?
In a simple way to detect the SRP violation, by asking a simple question before you make any changes: What is the responsibility of your class/component/microservice?
If your answer includes the word “and”, you’re most likely violating the single responsibility principle Also, all other facts that you can identify SRP violations.
- More than one contextually separated piece of code within a single class
- Large setup in tests (Test Driven Development is very useful when it comes to detecting SRP violation)
- The difficulty of reuse your class/method inside your project.
- If your class or method is too long (LOC > 250)
Why SRP?
The single responsibility principle is relatively simple, it makes your code easier to implement and prevents unexpected side-effects of future changes.
- Easier to Understand: Class/method/property that has only one responsibility so its easier to explain, understand and implement.
- Easier to Reuse Code: Separated classes responsible for given use case can be now reused in other parts of an application
- Easier to Fix Bugs: Easy to identify defects and fix the bugs in the code because of separated classes based on the responsibility.
- Easier to write optimal tests since the functionality provided by the class is much clearer.
- Dependency management aspects between classes become easier to manage since the code is grouped well.
- On-boarding a new team member is easier since the code is well-organized and easy to understand.
- Easier to code change (Refactoring)
Real-world examples of the Single Responsibility Principle
Let’s take an example: we have a class for placing the order.
In the above example, in the PlaceOrder class, we have a function called run() will do the operations of placing an order such as verifying stock availability, payment process and shipment process here we see a clear violation of SRP because this function does more than single work.
Let’s refactor this code:
Find it a good read?
Recommend this post (by clicking 👏 button) so other people can see it too…
reach me on
