Introduction
Continuing our discussion on S.O.L.I.D principle, checkout Open Closed Principle (OCP), Liskov Substitution Principle (LSP), Dependency Inversion Principle (DIP), Interface Segregation Principle (ISP) if not so far. In this blog lets cover yet another principle i.e. Single Responsibility Principle short hand (SRP). Let’s dive in.
Single Responsibility Principle
SRP states that
“Any class should have only one reason to change“
This statement looks well understood but what does it really mean from design perspective? Lets take an example suppose that we have a class which takes care of following
- Display the analytics data on UI (User interface)
- Pulling the analytics data from DB (Database).
Looking at this class, there are two reasons this class can get modified.
- If the format in which the data is displayed changes.
- Change in data delivery mechanism OR change in some data fields on DB side.
The above changes can happen anytime in the future, and they are independent in nature. If such change happens either on DB or the UI, it would break the other in some way. For instance if the data delivery mechanism OR some fields changes on DB side, the UI part will be affected.
It is above issue SRP tries to address, where in If these responsibilities were handled separately these issues can be avoided, and the design will be loosely coupled and more cohesive. Hope this clears the understanding.
Usage of Single Responsibility Principle in Android
In Android there are multiple services that handle only a single aspect of the system, for instance Location Manager Service only handles all the aspects of location, Connectivity Service only handles data connection aspects likewise other services.
Conclusion
In this we discussed SRP, in summary make sure each class handles a single concern, therefore class should have only one reason to change. you can explore the Android supported services here. Hope this blog helped, with this concluding the S.O.L.I.D principle explanation series.