SOLID Principles in JavaScript (4): What "I" Stands for

This article is the fourth part of the SOLID principles. It is recommended to read the first three parts first:

SOLID Principles in JavaScript Part 1: What "S" Stands for

SOLID Principles in JavaScript (2): What does "O" stand for

SOLID Principles in JavaScript (3): What does "L" stand for

This is the fourth article of SOLID (there are five original articles in total), the author is serhiirubets , welcome to continue to pay attention.

Interface Segregation Principle

I - Interface Segregation Principle . This principle states: Clients should not rely on interfaces they do not use (interfaces should be lean and have as few behaviors as possible).

What does this mean? This principle is about interfaces, but in JavaScript there is no interface, but there is something similar, and that is a class. Although the two are different, this principle can be applied to JS classes.

For JS classes, this principle means that when we create a base class, we need to define methods in it that all subclasses will use, and avoid methods that only some subclasses will use.

As a simple example, when we create a base class Transport and add the following methods: move, stop, fly and sail. The method in the example only adds console.log , which should correspond to real business logic in practical applications.

 class Transport {
  move() {
    console.log('move');
  }
  stop() {
    console.log('stop');
  }
  fly() {
    console.log('fly');
  }
  sail() {
    console.log('sail');  
  }
}

We create three more subclasses: Plane, Car and Ship.

 class Plane extends Transport {
  sail() {
    return null;
  }
}
class Car extends Transport {
  fly() {
    return null ;
  }
  sail() {
    return null;
  }
}
class Ship extends Transport {
  fly() {
    return null ;
  }
}

You may have noticed that each subclass overrides the inherited method and returns null . Why do this, take Plane as an example, the plane can fly and move, but not sail (boat sailing).

Our base class contains the sail logic, but the plane cannot be sailed. We should do something because someone might call the sail method on the plane instance and we can throw an error or override the sail method as we do now. The other two classes also use the same processing method, Car rewrites fly and sail, and ship rewrites fly.

So the problem is: the base class we created contains methods that some subclasses can use, but not others. This is what the Interface Segregation Principle is about: we shouldn't create logic in a base class that a subclass won't use.

Of course, this has nothing to do with polymorphism, if we create a common method, but every subclass will override the logic of this method, it's okay.

For example: we have a base Animal class that contains a breathe method, its subclasses can also breathe but in a different way, we can use polymorphism:

 class Animal {
  breath() {
    console.log('common breath')
  }
}
class Human extends Animal {
  breath() {
    console.log('lung breath')
  }
}
class Fish extends Animal {
  breath() {
    console.log('gills breath')
  }
}

Revisit the interface segregation principle again: correctly create methods in the base class, and these methods should be used by inherited subclasses.

So how do we solve the problem in the Transport class? We can create more specific subclasses that contain methods that only they will use:

 class Transport {
  move() {
    console.log('move')
  }
  stop() {
    console.log('stop')
  }
}
class FlyingTransport extends Transport {
  fly() {
    console.log('fly')
  }
}
class SailingTransport extends Transport {
  sail() {
    console.log('sail')
  } 
}
class Car extends Transport {}
class Plane extends FlyingTransport {}
class Ship extends SailingTransport {}

Now our Transport base class contains move and stop methods that can be used in all subclasses. We also created two concrete subclasses, plane can inherit FlyingTransport, and ship can inherit SailingTransport.

This is the meaning of the "I" in the "SOLID" principle: the main purpose of this principle is to have a good hierarchy of code, try not to create methods in the base class that the subclass does not need.

Welcome to the WeChat public account "Chaos Front End"