The SOLID Principles - Interface Segregation

The Interface Segregation Principle (ISP) states that clients should not be forced to depend on interfaces that they do not use. In other words, interfaces should be designed in a way that clients can use only the methods that are relevant to them, without being forced to implement methods they don't need.

Here are some examples of how the ISP can be applied in JavaScript:

Example 1: A Printer Interface

Suppose we have a Printer interface that has several methods, such as print(), scan(), fax(), and copy(). However, some clients of the Printer interface only need to print, while others may need to scan or fax as well.

Here's an example of how we can apply the ISP to the Printer interface:

interface Printer {
  print();
}

interface Scanner {
  scan();
}

interface Fax {
  fax();
}

interface Copier {
  copy();
}

class BasicPrinter implements Printer {
  print() {
    // Print document
  }
}

class AdvancedPrinter implements Printer, Scanner, Copier {
  print() {
    // Print document
  }

  scan() {
    // Scan document
  }

  copy() {
    // Copy document
  }
}

By splitting the Printer interface into smaller, more specialized interfaces, we can ensure that clients only depend on the methods they need, without being forced to implement methods they don't use.

Example 2: A Car Interface

Suppose we have a Car interface that has several methods, such as start(), accelerate(), brake(), and stop(). However, some clients of the Car interface only need to start and stop the car, while others may need to accelerate and brake as well.

Here's an example of how we can apply the ISP to the Car interface:

interface Starter {
  start();
}

interface Stopper {
  stop();
}

interface Accelerator {
  accelerate();
}

interface Braker {
  brake();
}

class BasicCar implements Starter, Stopper {
  start() {
    // Start car
  }

  stop() {
    // Stop car
  }
}

class AdvancedCar implements Starter, Accelerator, Braker, Stopper {
  start() {
    // Start car
  }

  accelerate() {
    // Accelerate car
  }

  brake() {
    // Brake car
  }

  stop() {
    // Stop car
  }
}

By splitting the Car interface into smaller, more specialized interfaces, we can ensure that clients only depend on the methods they need, without being forced to implement methods they don't use.

In both examples, we can see how following the ISP helps to create code that is easier to maintain, test, and reuse, since clients only depend on the methods they need, without being forced to implement methods they don't use.