Interface Segregation 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, in other words 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 force 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 implement the required set of interface(s).

If there is 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 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.



With ISP, the following image is a good example of segregation in our 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.

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

1.  A potential customer as described taht 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 meaningfull 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:

Disadvantages

1.  Deliver big fat interface that forces the client to implement a method that is not required.
2. The client ends up implementing a usefuless 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 sometime since it might perform some action that is not related to it.