An Introduction to SOLID Principles in Software Engineering

As it is said, code does not age like fine wine. It ages like milk. As time passes, the application gets bigger, and more programmers contribute to it, it grows to be more complicated, harder to understand, to improve and to maintain. To avoid it, we need some tools that will be used as a preventive measure. The SOLID principles have proven themselves to be a valuable tool in this direction, but what exactly is SOLID?

SOLID represents a set of five design principles intended to make object-oriented designs more understandable, flexible, and maintainable. The American software engineer Robert C. Martin (Uncle Bob) introduced these principles in his 2000 paper, “Design Principles and Design Patterns”. These principles have revolutionized the world of object-oriented programming, changing the way we write software.

What is the meaning of SOLID?

SOLID is an acronym, and each letter in the acronym represents a specific principle:

• S: Single Responsibility Principle (SRP): A class or a method should have only one reason to change. In essence, every class or method should have only one responsibility. Following this principle makes your software easier to implement and prevents unexpected side effects of future changes. It also makes the code easier to test, which provides a greater degree of certainty that the code functions in the way that it was intended to.

• O: Open-Closed Principle (OCP): Software entities should be open for extension but closed for modification. This principle encourages us to write code that doesn’t have to be modified every time the requirements change.

• L: Liskov Substitution Principle (LSP): Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. This principle ensures that a subclass can always be substituted for its superclass without causing any errors or unexpected behaviour.
For example, let’s take Class A and Class B, and assume that B extends A. The methods that are defined in A should be overridden in B but with a very important condition.
The behaviour of the methods in the subclass should not be different from the behaviour that the methods have in the superclass.

• I: Interface Segregation Principle (ISP): Clients should not be forced to depend upon interfaces that they do not use. In other words, a class should not implement an interface that defines methods which are not needed by the class. This principle helps to decouple software and makes it easier to refactor, change, and redeploy.

• D: Dependency Inversion Principle (DIP): Depend upon abstractions, not concretions. This principle leads to a system in which high-level modules do not depend on low-level modules — both should depend on abstractions.
In essence, abstractions are represented by the interfaces or by the base classes. By implementing this principle, we make sure that our dependencies are on the aforementioned abstractions, rather than being concrete implementations.
Correct implementation of the Dependency Inversion Principle encourages the usage of the software components across multiple applications.

Why are SOLID Principles Important?

The SOLID principles encourage us to create more maintainable, understandable, flexible and testable software. As the applications get bigger, it is inevitable due to the entropy that governs our world, that it will also grow in complexity.
By implementing the aforementioned principles, we can reduce their complexity and save ourselves a lot of problems in the future.
More specifically, these principles address a problem known as “Dependency Management”. Clear and well-defined dependencies between classes and methods are more likely to lead to flexible, sturdy, and maintainable programs.

Conclusion

The SOLID principles help structure and organize object-oriented software projects. These directives assist programmers in maintaining modularity and properly-structured class and interface design.
However, each principle represents a design goal, not an absolute law. Perfect adherence to every principle might not be possible in every case. Sometimes there might be valid reasons to take a different approach. But this should be only done after careful consideration after determining theprinciple is impractical.
It is our duty as software engineers to determine which case calls for which tool in our toolkit and to implement it. If we go and implement these tools blindly, we are not thinking, but just being zealotsto the dogma of our choice.

Sources for further reading

• https://en.wikipedia.org/wiki/SOLID

• https://www.baeldung.com/solid-principles

• https://www.freecodecamp.org/news/solid-principles-single-responsibility-principleexplained/