SOLID is an acronym for Robert C. Martin's (also known as Uncle Bob) top five object-oriented design (OOD) principles.
These principles establish practices that contribute to software development, with considerations for maintaining and expanding as the project grows. Adoption of these practices can also contribute to the prevention of code smells, code refactoring and Agile or Adaptive software development.
SOLID means:
S-Single Responsibility Principle
O-Open-Closed Principle
L-Liskov Substitution Principle
I- Interface Segregation Principle
D-Dependency Inversion Principle
In this blog, you will meet each principle individually to understand how SOLID can help make you a better developer.
Single Responsibility Principle
The Single Responsibility Principle states that a class must do only one thing and therefore only have one reason to change.
To put this principle more technically: Only a potential change in the specification of the software (database logic, logging logic, etc.) should be able to affect the specification of the class. This means that if a class is a data container, for example a Book class or a Student class, and it has some fields related to that entity, it should only change when we change the data model.
Open-Closed Principle
The Open-Closed Policy requires classes to be expandable and unmodifiable.
Modification means changing the code of an existing class, while extension means adding new functionality. So what this principle means is that we should be able to add new functions for the class without touching the existing code. This is because every time we change existing code, we run the risk of creating potential bugs. So we should avoid touching tested and reliable (mostly) production code whenever possible.
Liskov Substitution Principle
The Liskov Substitution Principle states that subclasses must be substitutable for their base classes.
This means that given that class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A, and in that case the method shouldn't give any weird output.
Interface Segregation Policy
Separation means keeping things separate and Interface Separation Principle is about separating interfaces. The policy states that many client-specific interfaces are better than a single general-purpose interface. Clients should not be forced to implement a function they do not need.
Dependency Inversion Principle
The Dependency Inversion principle states that our classes should depend on interfaces or abstract classes rather than concrete classes and functions.
