设计模式六大原则，带你看懂编程的底层逻辑-CSDN博客

本文链接：https://blog.csdn.net/qq_45464560/article/details/146779492

设计模式六大原则，带你看懂编程的底层逻辑

一、单一职责原则（SRP）[各司其职，简洁高效]
二、开闭原则（OCP）[拥抱扩展，拒绝修改]
三、里氏替换原则（LSP）[子类上位，无缝衔接]
四、依赖倒置原则（DIP）[面向抽象，解耦神器]
五、接口隔离原则（ISP）[按需定制，拒绝冗余]
六、迪米特法则（LoD）[保持距离，降低耦合]
总结

在这里插入图片描述

设计模式六大原则是构建高质量代码的基石，但很多教材中的例子过于抽象，导致理解困难。本文将通过生活化场景和实际代码案例，重新解读这些原则的本质，力求让你豁然开朗。

一、单一职责原则（SRP）[各司其职，简洁高效]

定义：对一个类而言，应该只有一类功能相关的职责
核心思想：避免“大杂烩式”代码，就像餐厅服务员不应该同时负责点菜、炒菜和结账。
经典案例：
假设有一个UserService类，同时处理用户登录、注册、发送邮件和记录日志。当邮件服务提供商更换时，修改邮件发送逻辑可能会意外影响登录功能。
改进方案：
拆分成四个独立模块：

LoginService：处理登录
RegisterService：处理注册
EmailService：发送邮件
LogService：记录日志

好处：修改邮件服务时，完全不影响其他功能，测试和维护更聚焦

二、开闭原则（OCP）[拥抱扩展，拒绝修改]

定义：对扩展开放，对修改关闭。
核心思想：像乐高积木一样拼装新功能，而不是拆掉旧模块。
经典案例：
电商订单系统需要支持多种折扣策略（普通用户、VIP、节日促销）。如果直接在订单类中写if-else判断用户类型，每次新增策略都要修改原有代码。
改进方案：

定义接口DiscountStrategy，包含calculateDiscount方法。
实现VipDiscountStrategy、FestivalDiscountStrategy等具体策略。
订单类通过依赖注入使用策略，新增策略只需扩展新类，无需修改原有逻辑

public class Order {
    private DiscountStrategy strategy;
    public Order(DiscountStrategy strategy) { this.strategy = strategy; }
    public double calculatePrice(double originalPrice) {
        return originalPrice * strategy.calculateDiscount();
    }
}

三、里氏替换原则（LSP）[子类上位，无缝衔接]

定义：子类必须能完全替代父类，且不破坏程序逻辑。
核心思想：继承不是“为了复用代码”，而是“为了表达逻辑一致性”。
经典反例：
让Penguin（企鹅）继承Bird（鸟类），但Bird有fly()方法。企鹅不会飞，调用fly()时抛出异常，这违反了父类契约。
改进方案：

拆分Bird为FlyingBird和NonFlyingBird
企鹅继承NonFlyingBird，燕子继承FlyingBird

关键点：继承前必须确认“子类是否满足父类的所有行为约定”

四、依赖倒置原则（DIP）[面向抽象，解耦神器]

定义：高层模块不依赖底层实现，二者都依赖抽象。
核心思想：像使用手机充电器一样，只关心USB接口，不关心内部电路。
经典案例：
数据库访问层直接依赖MySQL驱动代码，切换成Oracle需要重写所有SQL语句。
改进方案：

定义接口UserRepository，声明save()、findById()等方法。
实现MySQLUserRepository和OracleUserRepository。
业务逻辑层仅依赖UserRepository接口，数据库切换零影响

五、接口隔离原则（ISP）[按需定制，拒绝冗余]

定义：客户端不应被迫依赖它不需要的接口。
核心思想：不要逼用户买整个工具箱，而是按需选择螺丝刀或锤子。
经典反例：
一个多功能打印机接口Printer包含打印、扫描、传真方法。普通打印机只能打印，却被迫实现空扫描和传真方法。
改进方案：
拆分为三个接口：

Printable：打印
Scannable：扫描
Faxable：传真

普通打印机只需实现Printable，三合一设备实现全部接口

六、迪米特法则（LoD）[保持距离，降低耦合]

定义：一个对象应尽可能少了解其他对象。（只与“直接朋友”对话）
核心思想：像点外卖时，你只需要和外卖平台沟通，而不是直接联系厨师、骑手和餐厅老板。
经典案例：
经理需要统计员工工作量，若直接访问每个员工的WorkReport对象，一旦员工数据结构变化，经理类需要同步修改。
改进方案：

经理类只与TeamLeader交互。
TeamLeader封装统计逻辑，返回结果给经理。

// 错误实现：经理直接访问所有员工
manager.getEmployees().forEach(e -> e.getWorkReport().getHours());

// 正确实现：通过TeamLeader中介
manager.getTeamLeader().calculateTotalHours();