Interface Segregation

The Interface Segregation Principle states that Clients should not be forced to depend on methods they do not use.

  • Interface Segregation violations result in classes that depend on things they do not need.

  • Interface Segregation violations results increasing coupling and reducing flexibility/maintainability.

Few simple tips to follow:

  • Prefer small, cohesive interfaces to “fat” interfaces

  • Creating a smaller interface with just what we need

  • Have the fat interface implement your new interface.

  • The dependency of one class to another one should depend on the smallest possible interface.

As an example, lets take something from .Net framework and how we can gain using ISP =

In this case we are taking IOrderedQueryable<T> Interface.


This interface represents the result of a sorting operation and it implements

  • IEnumerable<T>

  • IEnumerable

  • IOrderedQueryable

  • IQueryable

  • IQueryable<T>

If we observe it, we can see how segregation is done and how IOrderedQueryable<T> is taking advantages of cohesive interfaces and creating its boundaries.

Refer: Refer: https://docs.microsoft.com/en-us/dotnet/api/system.linq.iorderedqueryable-1?view=netframework-4.7.2


One more example below:

  • In first case Deposit, withdrawal and transfer classes are all dependents on one interface. Just look at it, do we need to implement RequestDepositAmount or RequestTrasnferAmount in Withdrwal operation?

  • When ISP is followed, we can clearly segregate interfaces according to the operations.

Violation of ISP

Resolved violation with ISP