SOLID is just an acronym for the five design principles in Object Oriented Design by Robert.C.Martin famously known as Uncle Bob in the Clean Code Book. This post explains those design principles in a nutshell.
S stands for Single Responsibility Principle
A class should have single responsibility over a functionality.
Not only a class, any module should have a single responsibility. For Example, a class having login and sign up page is not following single responsibility principle. You should break it into two classes. Similarly, a method doSomethingAndOtherthing() is not following single responsibility principle. There should be two separate methods.
O stands for Open-closed Principle
This principle says the entities must be open be open for extension and closed for modification.
It means, when you create a class and writing the functionality in it, we are making it tightly coupled. Suppose, we have to change the entire functionality, we need to change the class and it may have lot of dependencies. So, when we know, there could be a change we need to program to interface and implement the functionality. When there is change in functionality, we could simply replace the underlying class implementation without affecting the dependencies.
L stands for Liskov Substitution Principle
This principle states that every subclass should be substitutable with their parent class.
This principle helps in reducing the coupling with extended features.
I stands for Interface Segregation Principle
This principle states that, a class must not implement a interface which contains the methods that a class do not need.
A class which implements an interface must implement all the methods the interface has. Here, the interface should be segregated into different interfaces and class must implement only the interface for which its going to provide implementations of the all the functions it is going to implement.
D stands for Dependency Inversion Principle
It states that high level entities must not depend on low level entities implementations but only on the abstractions.
For example, there is a class which connects to a database. Now, the connection class requires a low level entity the database driver. The connection class should only depend on the Driver interface which is the abstraction. There could be many implementations to this Driver class like Postgres driver, MySQL driver etc. Now, as a result the connection class need not be changed when the database changes. Also these low level implementations must be injected into the class.
