Interface Segregation Principle

Principle

A class that implements an interface shouldn't be forced to implement methods it does not use.

The Interface Segregation Principle is, in a way, the same as the Single Responsibility Principle, only for interfaces. It essentially says:

An interface should describe one set of behaviors.

In other words, keep interfaces small; break down a "fat" interface into several more refined interfaces.

Here is an example: imagine your software application integrates with AWS cloud computing provider. You came up with the following design, inspired by the Open/Closed Principle:

You thought with this design your application is open for extension (when the time comes to add another cloud computing provider) and close for modification (since you would not have to mess with the Amazon class that implements CloudProvider and connects to AWS). As you have anticipated, in later iterations, you add support for using Dropbox in your application. The class diagram then looks like this:

The problem, however, is that Dropbox does not provide the broad spectrum of behaviors declared in your CloudProvider. So, if a client calls getCDNAddress¹ on an object of type Dropbox for instance, you would have to let them know this feature is not supported by Dropbox.²

A better design would look like the following:

In this example, one bloated interface (CloudProvider) was broken down into a set of more granular interfaces (CloudHostingProvider, CDNProvider, CloudStorageProvider).

Similar to the Single Responsibility Principle, the goal of the Interface Segregation Principle is to reduce the adverse effect of required changes by splitting the software into multiple, independent parts.

Case in point

By following this principle, you prevent bloated interfaces that define methods for multiple responsibilities. As explained in the Single Responsibility Principle, you should avoid entities with multiple responsibilities because they change more often and make your software hard to maintain.