Hello guys, this is the fourth part of SOLID Principles in JavaScript and if you haven't read the previous three ( , and ), I highly recommend reading them first and coming back here. first part second part third part " " - Interface Segregation Principle. This principle says: clients should not be forced to depend upon interfaces that they do not use. I What does it mean? This principle says about the interface, but as we know, we don't have interfaces in Javascript. But, in Javascript we have something similar to them, it's classes. Of course, it's not the same, but this principle could be applied to JS classes. So, if we speak about classes, this principle means that when we create a base class, we should declare all methods that will be used in subclasses and try to avoid methods, that some subclass will use, but some another subclass shouldn't use. Let's take an example. Let's create a base class for transports with the next methods: move, stop, fly and sail. For this example, methods will contain just , but of course, in real life, it will be real business logic. console.log As you can see, nothing hard. And let's create 3 subclasses: plane, car, and ship. You maybe noticed, that in each subclass we rewrite inherited methods and put . Let's speak about why. Think about the plane. The plane can fly, can move, but the plane can't sail. return null Our base class contains logic for the sail method and of course Plane can't sail. We should do something because someone could call this method at a plane instance. We can throw an error or rewrite this method as it is now. The same with the other two classes, car, and ship. Car can't fly and sail. The ship can't fly. So, the problem is we created in base class methods, that some subclass can use, but others can't. . This is what the interface Segregation Principle says. We, shouldn't create logic in a base class, which shouldn't be in a subclass. Of course, it isn't relative to polymorphism. If we should prepare a common method, but each child should rewrite logic, it's ok. Just for example: If we have an Animal base class, which can breathe and we have subclasses, who also can breathe, but in a different way, we use polymorphism and it's ok: Let's repeat that the "Interface Segregation Principle" is about creating correct methods in the base class, which will be used by inheritors. How can we fix the problem with the Transport class? We can create more specific subclasses, where we will contain only needed methods to our subclasses: Now, we have base class Transport that can move and stop. 2 methods, that will use all subclasses. And we created more specific subclasses for flying transport and for sailing transport. And then, plane inherits from flying class, ship inherits from sailing class. The "I" of the SOLID Javascript Principle So, the main purpose of this principle is to prepare a hierarchy of a good way and try not to create methods in a base class, which aren't needed in subclasses.

Different

2022 - HackerNoon Contributor of the Year - Best Practices

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Functional Programming

2022 - HackerNoon Contributor of the Year - Performance

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Performance

Nominated for 2022 - HackerNoon Contributor of the Year - Functional Programming

Nominated for 2022 - HackerNoon Contributor of the Year - Best Practices

Too Long; Didn't Read

In your car, at home, or at work — Bosch technology shapes many areas of life.

SOLID Principles in JavaScript: What Does the "I" Stand For?

SOLID Principles in JavaScript: What Does the "I" Stand For?

Too Long; Didn't Read

Company Mentioned

Serhii Rubets

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

SOLID Principles in JavaScript: What Does the "I" Stand For?

Too Long; Didn't Read

Company Mentioned

Serhii Rubets

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES