Tuesday, 7 July 2020

SOLID Design Principles in C# - Interface Segregation Principle (ISP)




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. 

Blog Post Interface

public interface IBlogPost
{
void CreateNew(Post postDetails);
void UpdatePost(Post postDetails);
void DeletePost(int postId);
void Publish(int postId);
void ArchivePost(int postId);
void UpdateHashTags(int postId, string[] hashTags);
List<Post> SearchByHashTag(string hashTag);
void DeleteHashTags(int postId, string[] hashTags);
void UpdateLocation(int postId, string location);
void DeleteLocation(int postId);
}

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.

Interface Segregation Principle Implementation

public interface IBlogPostService
{
void CreateNew(Post postDetails);
void UpdatePost(Post postDetails);
void DeletePost(int postId);
void Publish(int postId);
void ArchivePost(int postId);
}

public interface IHashtagsService
{
void UpdateHashTags(int postId, string[] hashTags);
List<Post> SearchByHashTag(string hashTag);
void DeleteHashTags(int postId, string[] hashTags);
}

public interface ILocationService
{
void UpdateLocation(int postId, string location);
void DeleteLocation(int postId);
}

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.


No comments: