Stuck with SOLID Principles? Let’s make it easy to understand.
May 16, 2021 3 min read
What is SOLID
The SOLID principles are a set of five guidelines for designing object-oriented software that was introduced by Robert C. Martin. These principles, when followed, can lead to more maintainable and scalable code.
Word ‘SOLID’, represents five different principles.
1. Single Responsibility Principle (SRP)
A class should have only one reason to change. In other words, a class should have only one responsibility or job. This helps to reduce the complexity of a class and make it easier to understand and maintain.
For example, consider a class that is responsible for both saving data to a database and sending email notifications. If the requirements change and the email notification feature needs to be modified, the class will have to be changed. This violates the Single Responsibility Principle because the class has more than one responsibility. A better design would be to have two separate classes, one for saving data to the database and another for sending email notifications.
2. Open-Closed Principle (OCP)
Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that it should be possible to add new functionality to a class without changing its existing code.
For example, consider a class that calculates the area of a shape. If you want to add support for a new type of shape, you should be able to do so by writing a new class for the new shape, without modifying the existing class that calculates the area. This allows the existing code to be reused and makes it easier to add new functionality.
3. Liskov Substitution Principle (LSP)
Subtypes must be substitutable for their base types. In other words, if a class is a subtype of another class, it should be able to be used in the same way as the base class without causing any issues.
For example, consider a class hierarchy for shapes, where the base class is Shape and there are subclasses for Circle, Rectangle, and Triangle. If a function expects an object of type Shape, it should be able to work with objects of any of the subclasses (Circle, Rectangle, and Triangle) without any issues. If this is not the case, it violates the Liskov Substitution Principle.
4. Interface Segregation Principle (ISP)
Clients should not be forced to depend on interfaces they do not use. This means that a class should not have to implement methods that it does not need.
For example, consider an interface for a logger that has methods for logging messages, warnings, and errors. If a class only needs to log messages and warnings, it should not be forced to implement the method for logging errors. This can lead to unnecessary complexity and make the class more difficult to understand and maintain.
5. Dependency Inversion Principle (DIP)
High-level modules should not depend on low-level modules. Both should depend on abstractions. This means that classes should depend on abstractions (such as interfaces) rather than on concrete implementations.
For example, consider a class that retrieves data from a database. Instead of directly depending on a specific database implementation (such as MySQL or PostgreSQL), it should depend on an abstraction (such as an interface) that defines the method for retrieving data. This allows the class to be more flexible and easier to maintain, as it can be used with different database implementations without any changes.
