In our previous posts, we have explored in depth several of the SOLID Principles, a set of essential guidelines in the world of object-oriented programming that radically transform the way we design and structure our code.

Today we are going to talk about the fourth of the principles, this one is known as ‘.‘Interface Segregation Principle‘ or in English ‘Interface Segregation Principle’.

What is the Interface Segregation Principle of the SOLID principles?

This principle tells us that a class should never extend interfaces with methods that it does not use. By the principle of interface segregation, it seeks to make interfaces as small and specific as possible so that each class only implements the methods it needs.

How to detect that we are violating the principle of interface segregation?

• We will be violating this principle if we have classes that implement methods of interfaces that are not used.

• Another case of violation of the principle would be when we define interfaces with parameters that are not going to be used in all classes.

• Another sign that we are skipping the principle will be when we have very large interfaces. We are probably defining methods that are not generic and that other classes that implement this interface cannot use.

How to solve the violation of the principle?

We can solve the violation of the principle by splitting large interfaces with methods that not all implementing classes use, by smaller classes with methods used by the classes.

In the case that we have interfaces with defined parameters, we must evaluate if it is a common element among the classes that implement that interface. And, if it is not, we will have to eliminate them.

Example of WRONG implementation of the interface segregation principle

We have the following defined interface (animal):

export default interface AnimalInterface {
  run(),
  eat(),
}

and the following two classes that implement it (dog and fish)

import AnimalInterface from "./AnimalInterface";

class Dog implements AnimalInterface {
  eat() {
    console.log('eating...')
  }

  run() {
    console.log('running...')
  }
}

import AnimalInterface from "./AnimalInterface";

class Fish implements AnimalInterface {
  eat() {
    console.log('eating...')
  }

  run() {
    throw new Error('Method not implemented')
  }
}

As you can see we are making a bad implementation of the principle because we are creating an interface that does not meet the requirements that all classes are implementing their methods.

Example of a CORRECT implementation of the interface segregation principle.

In this example we are going to take the previous base case and solve it using the principles correctly.

In view of the fact that not all animals can run, such as fish in the previous case, we will divide the animal interface into two parts:

export default interface EatInterface {
  eat();
}

export default interface RunInterface {
  run();
}

Now we will implement the interfaces depending on the class we are creating. In this case, since fish can't run, we won't implement RunInterface, but as if they can eat we will implement EatInterface.

In the case of dogs as they can eat and run we will implement both classes:

import EatInterface from "./EatInterface";

class Fish implements EatInterface {
  eat() {
    console.log('eating...')
  }
}

import EatInterface from "./EatInterface";
import RunInterface from "./RunInterface";

class Dog implements EatInterface, RunInterface {
  eat() {
    console.log('eating...')
  }
  run() {
    console.log('running...')
  }
}

This post is part of our series dedicated to the SOLID Principles, where each principle is a key piece in building a cleaner and more professional code. Previously we were talking about the third principle, Liskov Substitution Principle.

In the coming weeks, we will delve into the last of these principles, thus closing our series with a comprehensive understanding of these essential practices in object-oriented programming. Stay tuned for that next chapter, and in the meantime, we encourage you to apply what you've learned and continue to raise the quality of your code.