SOLID Principles
SOLID is an acronym that contains five design principles in the software development.
- Single Responsibility principle
- Open-Closed principle
- Liskov Substitution principle
- Interface Segregation principle
- Dependency Inversion principle
The author Robert C. Martin warns without good design principles, the software becomes rigid, fragile, immobile and viscous.
The broad goal is reduce the dependency that exists between the members of a development team.
Single Responsibility
The principle means that each class only does one thing and has only responsibility. Every class or module should solve only one problem.
A class should have one, and only one reason to change.
It helps when you need to do a modification on specific functionality, thus you can go into the unique place to do that.
Open-Closed
One time that you have finished coding a class, this class shouldn't be modified.
Well-tested classes won't need to be modified when something needs to be added. Instead of changing the class, you simply want to extend it.
You should be able to extend a class behavior without modifying.
- Open for extension means that the class's behavior can be extended.
- Closed for modification means that the source code is set and can't be changed.
Liskov Substitution
Broadly, this principle simply requires that derived class should be substitutable for its parent class.
If you have a child class that inherits from a parent class, this child class must not change the parent class functionality.
The principle helps to avoid unexpected consequences of changes and avoids having to open a closed class in order to make changes.
Interface Segregation
The principle says it's better to have a lot of small interfaces (thus, classes) than a few bigger ones.
Make fine grained interfaces that are client-specific. Clients shouldn't be forced to implement interfaces they don't use.
Dependency Inversion
It Offers a way to decouple software modules. It says the high level modules shouldn't depend low level modules
Depend on abstractions, not on concretions
That allows us decide the specific implementation of each element.
Conclusion
Using SOLID principles during your development helps to get systems more maintainable, scalable, testable and reusable.
It helps us to write better code. But don't forget that you should avoid being excessive when using these principles, especially in the places that don't have a necessity.