SOLID programming principles
Hello, I’m Yasiru Navoda Jayasekara. Today I’m going to explain SOLID programming principles & the importance of using those principles.
Introduction
As a developer, when designing software we have to follow some standard principles. The SOLID principle is one of the most popular software design principles. This has five key design principles. All five are widely utilized by software engineers and offer significant advantages to developers. S.O.L.I.D is an acronym for Michael Feathers, a subset of the principles expressed by Robert Martin. The five design principles are as follows.
S → Single responsible principle
O → Open/Close principle
L → Liskov substitution principle
I → Interface segregation principle
D → Dependency inversion principle
1. Single Responsibility Principle
“A class should have one, and only one reason to change.”
This principle says that each class does just one task and that each class or module is responsible for only one part of the software’s operation. Simply said, each class should only work on one problem.
Using this principle makes code easier to test and maintain software easier to implement, and future modifications less likely to have unintended consequences.
2. Open/Close principle
“Objects or entities should be open for extension, but closed for modification”
Open for an extension means that the behavior of the class can be extended, while Closed for modification means that the source code has been set and cannot be changed.
As an example, We need abstractions to be able to expand the behavior of a class without modifying a single line of code.
This is because modifying a class after it has been created and is being used by systems risks causing a massive break with inconsistent behavior between the two versions of the class.
3. Liskov substitution principle
“Parent classes may easily be substituted with their child classes without blowing up the application,” according to this principle.
While this is a challenging principle to absorb, it’s essentially an extension of the open-closed principle in that it ensures that derived classes expand the base class without affecting its behavior.
Following this principle helps code become clear and reduce the complexity and much easier to debugging.
4. Interface segregation principle
“Clients should not be forced to implement methods they do not use”
You can avoid bloated interfaces that define methods for various responsibilities by following to this principle. You should avoid classes and interfaces having numerous responsibilities since they change often and make your software difficult to maintain, as outlined in the Single Responsibility Principle.
5. Dependency inversion principle
“Higher level modules should not depend on lower level modules, but they should depend on abstractions”
Developers should “depend on abstractions, not concretions,” according to the dependency inversion principle. Martin elaborates on this principle by stating that “high level modules should not depend on low level modules.” Abstractions should be used in both cases. “Abstractions should not be dependent on specifics,” says the author. Abstractions should be the basis for details.”
Conclusion
When SOLID design principles are followed during development, systems become more manageable, scalable, tested, and reusable. Engineers use these principles all around the world in today’s world. As a result, it’s critical to follow these principles in order to write quality code and use design principles that are competitive while fulfilling industry standards.
