Interface Segregation Principle

Before going through this article, I strongly recommend reading my previous articles.

• What is the Single Responsibility Principle
• Open-Closed Principle in SOLID
• Liskov Substitution Principle

The Interface Segregation Principle is one of the SOLID principles defined by Robert C. Martin. It is one of the rules of software development that says to always code according to a contract, in other words, an interface, not against the implementation, a concrete class, because coding against an interface provides advantages like flexibility, loose coupling, testable code, and so on. This principle is related to creating an interface for implementation.

The principle says “Client (class implementation interface) should not be forced to implement Interface that they don't use.” In simple words the principle is saying, do not design a big fat interface that forces the client to implement a method that is not required by it, instead design a small interface. So by doing this class only implements the required set of interface(s).

If there is a big fat interface then break it into a set of small interfaces with the related method(s) in it. It's similar to normalizing our database like normalizing the database from 1NF to 3NF where a big table is broken into tables with related columns.

Interface segregation principle in real life

In terms of the violation of the ISP, the following image shows a big dustbin for throwing all kinds of garbage away without any kind of segregation.

Figure 1. Dustbin

With ISP, the following image is a good example of segregation in our real life.

Figure 2. ISP in Real Life

That is an image of a waste bin segregation that shows which one to use for throwing away trash we use.

Example of ISP in Application Development

Here is an example of a banking customer for a bank with the following types of customers.

1. Corporate customer: For corporate people.
2. Retail customer: For individual, daily banking.
3. Potential customer: They are just a bank customer that does not yet hold a product of the bank and it is just a record that is different from corporate and retail.

The developer of a system defines an interface for a customer as in the following that doesn't follow the ISP rule.

Figure 3. Interface for customer

It looks OK at first glance but it's a big fat interface for the customer with the problem since it forces the client class to implement methods that are not required.

1. A potential customer as described that does not hold any product is forced to implement a product property.
2. A potential customer and a retail customer both are forced to have a Customer Structure property but in a real scenario, a Corporate customer has a Customer Structure that describes a customer hierarchy.
3. A potential customer and a retail customer both are forced to implement a BusinessType but that just belongs to a corporate customer.
4. A corporate customer and a potential customer are forced to implement an Occupation property that is just a blog to a retail customer.

A solution to the preceding problem is to split the fat interface into meaningful parts, in other words, small interfaces, so the customer type only implements the interface that is required by it.

The following is an image that follows the ISP

Figure 4: Interface

Disadvantages of ISP

1. Deliver a big fat interface that forces the client to implement a method that is not required.
2. The client ends up implementing a useful method, in other words, a method that has no meaning to the client. This decreases the readability of the code and also confuses the developer using the client code.
3. The client interface ends up violating SRP sometimes since it might perform some action that is not related to it.

Further Read

• Dependency Inversion Principle