The SOLID Principle for solid coding

Solid principle

As a Frontend engineer, we often hear about adhering to fundamental coding principles, but what exactly are these principles? Let’s discuss a fundamental one: the SOLID principle. This blog will talk about the SOLID principle without providing examples with code, allowing you to visualize the application on your own.

Single Responsibility Principle -

A class should have just one reason to change.

Any Class that can expands its logical domain or compiles multiple features should be encapsulated for a single feature.

Open/Closed Principle -

Classes should be open for extension but closed for modification

Any Class that we have to modify to adjust new changes if the subclass not able to fulfill the functionality needed in the new changes, that means the class is not open for modification and requires code changes.

Liskov Substitution Principle -

When extending a class, remember that you should be able to pass objects of the subclass in place of objects of the parent class without breaking the client code.

What it means is

• If the class Ahad a method i.e., fun(a: B) with class B as a type then any subclass of A can inherit the method fun but type of a should be a superclass of B or B itself , it cannot be a sub-class of B and it should not strength the pre-condition i.e., if B was of type int and later in the subclass method fun throws error for all the positive number except the negative numbers then if client code decied to use this subclass object and it will throw the error.
• If the class Ahad a method i.e., fun(a: C): B with class B as a return type then any subclass of A can inherit the method fun but the return type of method fun should be class B or sub type of class B
• A method in a subclass shouldn’t throw types of exceptions which the base method isn’t expected to throw.
• On a weak typed language like JavaScript, sub class shouldn’t change the value of private fields of super class.

Interface Segregation Principle

Clients shouldn’t be forced to depend on methods they do not use

Image it like this, a superclass has one relational logic attached to it with but have different method for different interpretation of this logic, but if a client has no use for certain interpretation, then what the point of enforcing the client to implement their own version of interpretation.

Dependency Inversion Principle:

High-level classes shouldn’t depend on low-level classes. Both should depend on abstractions. Abstractions shouldn’t depend on details. Details should depend on abstractions.

Observations: I have seen this principle referenced on a closed coupling classes or cases, for example, connecting backend with database or some third-party services like stripe or anything.

Here High level class means, classes which defines business logic and tells low level class to perform some action like initiate a payment and low level class will then implement the operation of making a new payment.

In general, we implement the low-level class first and then move to high level class.

Consider the example where objective is to provide support of different payment method while checkout and we now want to support for multiple payment type, i.e., Stripe, PayPal and many more.

The ideal structure of dependency injection principle will look something like this -

Most of the time we have come across these principles, we intentionally or un-intentionally maybe using it also, but we were not aware.