SOLID Design Principles: The Interface Segregation

Introduction

In today’s article, I am going to talk about the Interface Segregation principle, and the purpose of implementing it with a real time example.

Before moving on to the interface segregation principle, I encourage you to read my previous articles on Single Responsibility, Open Closed and Liskov Substitution principles.

SOLID Design Principles: The Single Responsibility

SOLID Design Principles: The Open Closed

SOLID Design Principles: The Liskov Substitution

What is Interface Segregation Principle?

The interface segregation principle (ISP) states that no client should be forced to depend on methods it does not use. ISP splits interfaces that are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Let’s break it down in a simpler manner:

1. No class should be forced to implement any method that they are not required to use.
2. To achieve the first one, we should be dividing interfaces (or rather fat size interfaces) into smaller interfaces so that the class which wishes to implement specific methods can implement from specific interfaces they need.
3. If we achieve pt. 1 and pt. 2, then your client is only looking for those methods or classes which they need to implement which help you to expose only what is needed for your client.

Let’s go back to history to understand how and why ISP got introduced and how it resolved the problem. We will take the same example to illustrate how to implement ISP.

“The ISP was first used and formulated by Robert C. Martin while consulting for Xerox. Xerox had created a new printer system that could perform a variety of tasks such as stapling and faxing. As the software grew, making modifications became more and more difficult so that even the smallest change would take a redeployment cycle of an hour, which made development nearly impossible.

The design problem was that a single Job class was used for almost all of the tasks. Whenever a print job or a stapling job needed to be performed, a call was made to the Job class. This resulted in a ‘fat’ class with multitudes of methods specific to a variety of different clients. Because of this design, a staple job would know about all the methods of the print job, even though there was no use for them.”

- Source Wikipedia

Let’s try to formulate the problem and then later try to solve it with the ISP.

If you take a look at the above Class diagram, the IJob interface consists of different functionalities that are required for a Xerox machine. And the Job Class implementing IJob interface with the methods to perform those functionalities for Xerox machines. At first glance you may say that it looks perfect as these many functionalities are required by Xerox machines to perform. But here are the problems it may lead to:

1. If you need to add a few more functionalities in the interface, then the Job class needs to be updated in order to implement them despite it is not being needed by class. (Violating open closed principle)
2. If you keep adding different functionalities then your Job class may end up having a lot of functionalities like a big fat class which does everything. (violating single responsibility principle)
3. It will become difficult for developers and testers to keep adding features as it may lead to more efforts in testing and ultimately on deployments as the whole Job class needs to be tested out every time.
4. There are also high chances that while editing or updating new functionalities in class, it may affect the other functionality.
5. From a client perspective, it is not necessary that they wish to use all the functionality being offered by Job class. They may look for say Print() and Fax() functionalities to use but end up knowing all the other functionalities offered by Job class.

So how are we going to solve the problem to ensure the client is not forced to use or implement features that they are not interested in?

Let’s understand the above Class diagram which helps to solve our problem using ISP.

1. One single interface IJob is now divided into smaller interfaces. Depending upon your business need, you can segregate multiple methods into one interface considering they are must for the particular behavior to execute or inter-related.
2. Here we created 4 different interfaces:
   - IPrint interface: which does Print() operation
   - IScan interface: which does Scan() operation
   - IFax interface: which does Fax() operation
   - IStaple interface: which does Staple() operation
3. Now, depending upon the client’s need, we can implement these interfaces and expose the functionality to the client.
4. So, here we defined 3 different clients (classes) which does different operations (or rather does only those operations which they need):
   JobPrintAndScan class: only responsible for performing Print and Scan operations and implemented from IPrint and IScan interfaces.
   JobFax class: only responsible for performing Fax operation and implemented from IFax interface
   JobStaple class: only responsible for performing Staple operation and implemented from IStaple interface.

So, here we are not enforcing our clients (classes) to implement methods that they DO NOT wish to use and are able to achieve by segregating interfaces and then implementing wherever classes wish to.

So with the ISP approach what benefits it is offering?

1. Now your code looks decoupled and your classes are not dependent on each other.
2. Each interface or class defined is taking care of single responsibility which satisfies our single responsibility principle.
3. Each class is now implementing those methods which they need to use.
4. Any new feature needed to implement requires to add a new interface in the code and implement in the class wherever you want which satisfies our open closed principle.
5. Code is also now easier to maintain and deploy as the changes to specific functionality is going to affect only that particular method and not the entire module.

Conclusion

I hope with the above example, you have now understood how to use the ISP principle to solve real world problems.

If you enjoy the content I create and would like to show your appreciation, you can buy me a coffee!