A bunch of principles every developer should follow in order to write and maintain a cleaner code.
S - Single Responsibility Principle
It merely states that any entity in your project - a class, function, file, or a module should have a single responsibility, i.e. it should have only one reason to change.
If you see a single file, doing many different things which requires to get updated for multiple reasons, then that file needs to be broken down into different files, with each file having only one responsibility.
O - Open/Closed Principle
Well, the definition of it says that the code should be open for extensions, and closed for modifications, which actually means that the piece of code that handles multiple scenarios should NOT change if an extra scenario or case has been added.
It should be generalized enough to handle new cases automatically. Open/Closed Principle almost always gets violated whenever there is a switch case present in the code.
If a function contains a switch that is checking the value of a parameter, then that switch needs to be replaced by an operation which is common for all types of parameter that can be provided to it. The input to the function can determine what needs to happen to it.
L - Lizkov Substitution Principle
In terms of object-oriented programming, this principle states that is S is a subtype of T, then all instances of T can be replaced with S and everything should work fine.
In simple words what it means is - every sub class / sub type should be able to perform all operations as intended by the base class / base type.
As an example, lets take a duck and a penguin which extends the base class Bird. Lizkov Substitution principle will fail if Bird class will force it’s both the subclasses to fly, as only duck will be able to fly, not the penguin.
I - Interface Segregation
This principle states that whosoever is implementing an interface should implement all of the methods of that interface. If not possible, then the interface needs to be broken down into different interfaces so that the above principle works.
In JavaScript, we don’t have interfaces but we have classes, and this principle is still valid for JS as well. An interface or a set of methods can be applied to the class by using it’s prototype property and attaching those set of methods via Object.assign.
D - Dependency Inversion
This principle states that your high-level code should NOT depend upon the low level implementations of your dependencies.
Instead, have a middle-man or an adapter or a facade in between which handles all the low level implementations of your dependencies while giving your code a constant abstract idea of what can be achieved with those dependencies.
This is also known as the adapter or the facade pattern, wherein, even when the dependency changes, the high level code will remain intact as only the adapter needs to update.
