SOLID principles are five design principles which can be used to design components which are loosely coupled and testable.
Single Responsibility Principle
S in SOLID stands for Single Responsibility. The principle is stated as follows –
A component (a class, method or a function) must contain only one function to perform. It must have only one reason to change.
The core of this principle is that we shouldn’t create such components – these are hard to maintain and are not flexible. Instead create multiple classes that are dedicated to something – a repository that works over only a single Entity, a Service that does only one Domain functionality etc.
Open/Closed Principle
O in SOLID stands for Open/Closed. The principle is stated as follows –
Any component or module must be such that it is open to extension but closed for modification
Modifying a component which might be used in other components may result in more problems than before, since we end up testing more components than the one which is actually modified; for the modification shouldn’t cause any compatibility issues on the other modules.
The second phrase of the principle states – closed for modification and suggests the first phrase as the solution – open to extension.
The modules should be developed with their probable modification requests in mind and should be designed such that they embrace extension.
Liskov Substitution Principle
L in SOLID stands for Liskov Substitution. The principle states the following –
The descending classes should behave the same way as the base classes behave. Which means the type S can be used in any place where a type T is used, where S is a subtype of T.
We must ensure that components are built such they are substitutable to one another, just inheritance is not enough.
In other words, we shall have a behavior provided by a type be described by means of abstractions and let those abstractions be used where ever the type needs to be utilized.
Interface Segregation Principle
I in SOLID stands for Interface Segregation. The principle states as follows –
Interfaces must be designed in such a way that they should contain exactly and only those attributes and functionalities which are totally consumed by the client.
Simply put, the principle talks about the problem of partial interfaces and the plight of clients which have to implement them even though they aren’t needed.
Dependency Inversion Principle
D in SOLID stands for Dependency Inversion. The principle states the following –
High level modules should not depend on low-level modules. Both should communicate by means of abstractions.
This means that we should avoid direct dependencies of components during communication, and rather have their abstractions be used for the same.
The principle also talks about high-level and low-level modules – which are basically the modules which are abstract and close to the user while the Low level are close to the I/O or Hardware.
Found this article helpful? Please consider supporting!
