Introduction
Continuing our discussion on S.O.L.I.D principle, checkout Open Closed Principle (OCP), Liskov Substitution Principle (LSP), Dependency Inversion Principle (DIP) if not so far. In this blog lets cover yet another principle i.e. Interface Segregation Principle short hand ISP. Lets dive in
Interface Segregation Principle
If an interface is serving multiple clients then better to sub divide the fat interface, and create interfaces with methods keeping only the API’s needed by respective client
The above statement looks self explanatory, lets see why we needed this? Suppose If we don’t segregate the fat interface? then adding any new API in the fat interface that only needed by a specific client, Will also impact other clients as well. Due to the addition of this unrelated API, recompilation/redeployment of other clients is also needed. Which sounds like difficult to maintain design. So it does make sense to segregate.
What does ISP mean by sub-divide interfaces?
Does ISP mean for each client that is using the fat interface should get their own interface? Wouldn’t that create an explosion of too many interfaces, which in turn are difficult to maintain? Correct indeed, what ISP really means is better to categories the interfaces rather than create per client. In cases when two clients need the same API that API can be added to both the categories, it should not harm.
What to do if new APIs need to be added later?
Interfaces that are segregated with categories are bound to change. In cases when adding new APIs impacts the huge part of the design and needs huge support on redeployment. In such cases it is better to add separate interface and implement in the same service object.
But again we need to take care not to over do this because maintaining different categories and again different versions of it will always be difficult.
Usage of ISP in Android OS
Lets take an example of the Android Framework(AFW) interaction with the GNSS hardware subsystem? which is a perfect example of an ISP. If you see any hardware subsystem provides different details information which every client might not be interested in. For instance GPS subsystem, provides SV (Satellite Vehicle), Debug data, NMEA, Location and GNSS measurement information.
How does AFW handle this, it defines different interfaces for each of the functionality instead of having a fat interface. Though there is just one service(GPS service) implementation of all the interfaces. See the ISP AFW communicating with SOC chipset GPS service implementation.
Conclusion
In this blog we discussed ISP, in summary always categorise the interface instead of having one fat interface. You can also explore the Gnss subsystem here, I hope this explanation helps. In the next blog we will discuss yet another S.O.L.I.D principle.