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
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 【.NET】调用本地 Deepseek 模型
· CSnakes vs Python.NET:高效嵌入与灵活互通的跨语言方案对比
· DeepSeek “源神”启动!「GitHub 热点速览」
· 我与微信审核的“相爱相杀”看个人小程序副业
· Plotly.NET 一个为 .NET 打造的强大开源交互式图表库
2023-12-23 keycloak~从login-status-iframe页面总结如何跨域传值
2020-12-23 maven~多个plugin相同phase的执行顺序