SOLID原则

This Principle is the foundation for Design patterns in Software System. For acheiving flexibility and making code modular it is highly recommended that we abide by these principles.

Each letter in the word has different meaning to it which is as follows:

S → Single Responsibility Principle

Classes and methods in the class should have single responsibility to it. So as to avoid complexity of putting logic inside single method and single class. Designated responsibility for each class and methods makes the code readable, code maintenance is easy, provides fliexibility and modularity.

Most Widely Used Example → Spring Framework has divided the business logic of MVC, Service and Database related functions across various layers like Controller, Service, and Repository layer and making use of appropriate annotations.

Note → We should avoid using utility classes common in a package as developers tend to dump all the helping methods in these utility classes, instead we should have some private helper methods in the same class.

Example Use Case :

O → Open Closed Principle

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”

This can be achieved using Inheritance or creating Interfaces
which adds layer of abstraction, ensure loose coupling among the implementing classes, also if some code is common across these classes, then we make use of composition or inheritance.

Example Use Case :

Payment Application having different payment types like Credit Card, Paypal, Debit Card Payments which can be implemented using one common interface and in future if new Payment type is introduced that can be directly extended using new class.

In this case if we have to add new payment type like Pyapal in future we need to create new class of Paypal and do not need to change any other class and create the object of Paypal in main class and use the method.

L → Liskov Substitution Principle

Objects of superclass should be replaceable with objects of subclass without affecting correctness of program.

Example Use Case :

Consider vehicle abstract class with method rent and Car,
Truck extending this Vehicle class and providing the implementation, respectively.​ Another class Electric Vehicle extends Vehicle and has rent method implementation which depends on the result of its own method isCharged().​ So, it means it is violating the Liskov substitution principle because if Vehicle instance is Electric Scooter, then he will not be simply able to rent the scooter instead he needs to first charge also.

Liskov Substitution Principle Violation

We cannot replace Electric Scooter directly in the places where Vehicle instance is used in our main application hence it is violating Liskov Substitution Principle.

LSP Implementation :

We can directly pass object of Vehicle whether it is electic scooter which has both chargeable and vehcile implementations or simply a car class which only has vehcile interface implementation now the code will not break and this clearly follows Liskov Substitution principle.

Note : remaining principles covered in part 2 https://saumyaawasthi187.medium.com/s-o-l-i-d-principle-part-2-17ef9e2adb87