Why use SOLID principles?

Let’s look at the issues below that may occur in the code if we don’t adhere to the SOLID principles.

• The code may become tightly coupled with several components, making integrating new features or bug fixes challenging and sometimes leading to unidentified problems.
• The code will be untestable so every change will need end-to-end testing.
• The code may have a lot of duplication.
• Fixing one issue results in additional errors.

However, if we adhere to the SOLID principles, we can do the following:

• Reduce the tight coupling of the code, which reduces errors.
• Reduce the code’s complexity for future use.
• Produce more extensible, maintainable, and understandable software code.
• Produce the code that is modular, feature-specific, and is highly testable.

SRP (Single Responsibility Principle)

"A class should have only one reason to change."
- Robert C. Martin

When a class performs one task, it contains a small number of methods and member variables that are self-explanatory. SRP achieves this goal, and due to this, our classes are more usable, and they provide easier maintenance.

OCP (Open/Closed Principle)

"A software artifact should be open for extension but closed for modification."
- Bertrand Meyer

Add new code to improve quickly instead of changing the core code, which should be kept unique and reusable.

OCP can be implemented through inheritance or interfaces. The latter, also known as polymorphic OCP, allows for extension while keeping the original code closed for modification.

Liskov Substitution Principle (LSP)

Liskov Substitution Principle (LSP) states that the objects of a subclass should behave the same way as the objects of the superclass, such that they are replaceable. This rule generally applies to abstraction concepts like inheritance and polymorphism.

• The subclass should have all the methods of the superclass overridden.
• Vehicle -> Start Engine -> Car, which BiCycle will not have. Make two subclasses from Vehicle class.

Interface Segregation Principle (ISP)

The Interface Segregation Principle (ISP) is a design principle that does not recommend having methods that an interface would not use and require. Therefore, it goes against having fat interfaces in classes and prefers having small interfaces with a group of methods, each serving a particular purpose.

• Keep only the methods used by the class, not all the methods are required by all the subclasses.
• Example: The area example of square, rectangle having volume method for cube.

Dependency Inversion Principle (DIP)

The Dependency Inversion Principle (DIP) states that high-level modules should not depend on low-level modules, but rather both should depend on abstractions. The abstractions should not depend on details. Instead, the details should depend on abstractions.

• Headmaster and Faculty example. This is just adding abstraction in between class and subclass.
• The DIP reduces the number of dependencies among modules. It provides a layer of abstraction between lower and higher classes, allowing for changes in the lower class without making changes in the higher class. A few benefits of the DIP are as follows:
  • It allows for the flexibility and stability of the software.
  • It allows for the reusability of the application modules.
• High level modules should not be dependent on the low level modules i.e. Presentation Layer --> High Level Abstraction Layer --> Low Level Modules