solid不是教条，而是识别代码恶化信号的灯塔；srp按变化原因拆类，ocp用抽象+多态实现不改老代码扩新功能，lsp确保子类可无感替换父类，isp与dip通过接口拆分和依赖注入解耦模块。

直接说结论：SOLID不是教条，而是帮你识别“哪段代码开始难改、难测、难加新功能”的信号灯。它不保证代码自动变好，但能让你在类膨胀、修改牵一发而动全身、新加一个支付方式就要改七八个文件时，立刻意识到问题出在哪。

单一职责原则（SRP）：什么时候该拆类？

判断标准不是“这个类叫什么”，而是“它被修改的触发原因有几个”。比如 User 类里同时有 save_to_db()、send_email()、validate()，那它就有至少三个变化原因——数据库换方案、邮件服务商迁移、校验规则调整。任一改动都可能波及其他逻辑。

• 把数据模型（User）和操作行为（UserRepository.save()、EmailService.send()）彻底分离
• 避免在 __init__ 里做 I/O 或网络调用；初始化只负责状态赋值
• 方法层面也适用 SRP：process_order() 不该既校验库存又扣减又发通知——拆成 check_stock()、deduct_inventory()、notify_customer()

开闭原则（OCP）：如何让新功能不碰老代码？

核心是抽象 + 多态。不是“所有类都要先写抽象基类”，而是当发现“每次加一种图形/支付方式/日志后端，就得改同一个 calculate_area() 或 pay() 函数”时，就该引入抽象。

• 用 abc.ABC 定义协议，比如 class PaymentMethod(ABC)，要求实现 charge()
• 业务类（如 OrderProcessor）只依赖 PaymentMethod，不关心具体是 Alipay 还是 PayPal
• 新增支付方式只需新增一个类，注册进配置或工厂，老代码一行不动
• 警惕“if-elif-else 列表式扩展”——那是 OCP 的反模式，意味着你已经在修改封闭的部分

里氏替换原则（LSP）：子类真的能无感替换父类吗？

不是“继承了就能用”，而是“把父类变量换成子类实例后，所有原有测试仍通过”。常见翻车点：

提示词大师-python版

图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍

下载

• Rectangle 类有 width 和 height，Square 继承它并强制 width == height ——但调用方可能单独设 width，结果 height 被意外改掉
• 父类方法抛 ValueError，子类改成抛 CustomValidationError ——上层 except ValueError 就捕获不到
• 子类重写方法时缩小了参数范围（如父类接受任意 int，子类只接受正数），调用方传负数就会崩

真正安全的做法：要么不用继承，用组合（Square 持有 Rectangle 实例）；要么确保子类契约完全兼容父类契约。

接口隔离与依赖倒置（ISP & DIP）：为什么你的模块总在互相拖累？

ISP 是说别让一个类被迫实现它用不到的方法；DIP 是说别让高层模块直接 import 低层模块的具体类。两者常一起出现。

• 如果 ReportGenerator 只需要导出 PDF，却必须实现 export_to_csv()、export_to_json()（哪怕空实现），就是 ISP 被违反
• 解决方式：拆成 PdfExporter、CsvExporter 等小接口，ReportGenerator 只依赖它需要的那个
• DIP 要求 ReportGenerator 构造时接收一个 PdfExporter 实例（或其抽象），而不是自己 import pdf_exporter 并调用 pdf_exporter.export()
• 实际落地最简单的方式：用函数参数注入依赖，而非模块内硬编码创建对象

复杂点在于，SOLID 的五条原则会相互制约——比如为满足 LSP 可能要放弃某些继承设计，转而用组合，这又影响 ISP 和 DIP 的结构。没有银弹，只有根据当前修改成本、测试覆盖度、团队理解力做权衡。最容易被忽略的是：不写测试，就根本无法验证是否真满足 LSP 或 OCP。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！