This is the 3rd article in our series of articles covering the SOLID Design Principles.

If you are unaware of SOLID, you can read the first article where I gave a brief introduction to SOLID. In this article, we will be covering the Interface Segregation Principle.

What is Interface Segregation Principle?

It states that the client should not be forced to implement an interface that it doesn't use.

Now, this definition doesn't really make any sense. So let's simplify this.

In simple words, the classes in your code or any other entity in your code should not be dependent on methods that they cannot use.

Example

Let's clear the concept with the help of an example.

Consider you are building a movie streaming app and you have 2 kinds of users: free users and premium users.

Premium users can watch both the trailer as well as the movie. However, free users can only watch the trailer.

Naive Solution

We can code this app something like this:

class User {
  constructor(name) {
    this.name = name;
  }

  watchTrailer() {
    console.log("Watching trailer...");
  }

  watchMovie() {
    console.log("Watching movie...");
  }
}

class PremiumUser extends User {}

class FreeUser extends User {
  watchMovie() {
    return null;
  }
}

Here, we created a User class with a name property and watchTrailer and watchMovie methods. Then we have 2 children: PremiumUser and FreeUser.

Inside of FreeUser, we override the watchMovie method and here it returns null which means it does nothing so free users cannot watch a movie.

What's wrong with this solution?

In our solution, FreeUser is depending on the watchMovie method but it cannot use that method because we are returning null. We can still call that method but it does nothing meaningful.

And here we are violating the Interface Segregation Principle because our FreeUser class is depending on a method that it doesn't use.

Better Solution

class User {
  constructor(name) {
    this.name = name;
  }

  watchTrailer() {
    console.log("Watching trailer...");
  }
}

class PremiumUser extends User {
  watchMovie() {
    console.log("Watching movie...");
  }
}

class FreeUser extends User {}

In this solution, we only put the common methods in the parent class, in our case it is just the watchTrailer method because every user can watch the trailer. And then PremiumUser has its own watchMovie method. Now any of our class is not depending on any method that it cannot use. FreeUser is now independent of the watchMovie method.

Hence, we are not violating the principle anymore because each of the class only has those things that it can use.

So that's it. Comment below if you have any questions. Will see you in the next article covering the Dependency Inversion Principle.

Follow me on:
Twitter
LinkedIn
Github