Definition of the Interface Segregation Principle?
Clients should not be forced to depend upon interfaces that they do not use.
The aim of the Interface Segregation Principle is to divide a fat interface
into multiple small interfaces.
Assume that we have a requirement from client which he needs a blog service
which will provides a following features.
1. Blog post should have Create, Update, Delete and Archive features.
2. Supports posting along with HashTags, and search post by HashTags.
3. Capture user location, and provide a provision to delete and update
location.
So we have added all these features in one interface tested and delivered to
client.
Assume that we have marketed our product and given this to multiple clients.
Can you imagine for a minute what challenges we face in future with this fat
Interface?
1. Should all clients are forced to implement all the methods in this
interface or not?
2. If any one client approaches us and said he do not want location feature
for him. What challenges do you face?
3. If any client asked to remove location and add mobile and email address
features to the post What challenges do you face?
4. What if any of the feature is not working among them in the interface?
5. How maintenance will be taken care in the production.
6. What testing efforts do we need put if we modify this Interface,
shouldn't we test all the features along with the intended one?
7. Is it not violating Single Responsibility Principle?
This is where Interface Segregation Principle will help in solving the above
problems. Lets refactor code by considering the high cohesion methods and
separate them into the multiple interfaces.
We have segregated the fat interface into multiple small interfaces with the
greater cohesion. Let's re look at the issues we considered above.
1. Should all clients are forced to implement all the methods in this
interface or not?
- Clients can utilize the required services and leave the rest.
2. If any one client approaches us and said he do not want location
feature for him. What challenges do you face?
- In this case client won't even come to us, because he has a
provision to avoid ILocationService.
3. If any client asked to remove location and add mobile and email address
features to the post What challenges do you face?
- We can add new Interfaces which supports the phone and email
features. Ex: IMobileService, IEmailService.
4. What if any of the feature is not working among them in the interface?
- Rather than modifying the code in fat interface we can fix the code
only in the service which has the issues.
5. How maintenance will be taken care in the production.
- Maintenance is less compared to maintaining the fat interface. How?
you can check the 4th point.
6. What testing efforts do we need put if we modify this Interface,
shouldn't we test all the features along with the intended one?
- We do not need to test all services which we provided, testing the
services which we fixed the issues is enough.
7. Is it not violating Single Responsibility Principle?
- As every service is segregated with the high cohesion it is
satisfying the Single Responsibility Principle.
Conclusion:
Interface Segregation Principle will not force the client to use all the
methods in interfaces, he has the provision to utilize and avoid as per his
needs.
Please check my below posts on other SOLID principles for better understanding.
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Dependency Inversion Principle (DIP)
No comments:
Post a Comment