solid原则是重构遗留代码的导航工具而非万能公式：srp指导拆分上帝类、ocp建议为变化点预留扩展、lsp防范伪继承风险、isp与dip协同降低耦合。
SOLID原则在重构遗留代码中不是万能公式，但确实是极有价值的导航工具——关键在于理解每条原则解决的具体问题，而非机械套用。
单一职责原则（SRP）：识别和拆分“过度承载”的类
遗留系统中最常见的问题是“上帝类”（God Class），一个类既处理数据校验、又拼接SQL、还负责日志和返回格式。SRP提醒你：这不是代码“功能多”，而是职责混淆。重构时，可先通过代码扫描（如调用频次、修改热点、依赖广度）定位高耦合模块；再按行为边界（如“解析”“转换”“持久化”）横向切分，而非按技术层（如“Controller/Service/DAO”）纵向分层——后者在遗留系统中常已失真。
- 观察方法命名：若一个类里同时存在 validateXxx()、buildSqlForXxx()、logErrorAndNotify()，大概率违反SRP
- 优先提取“副作用密集”的逻辑（如发消息、写文件、调外部API），它们天然构成独立职责
- 拆分后不急于重命名包结构，先确保编译通过、测试绿灯，再逐步调整命名与组织
开闭原则（OCP）：为变化点预留扩展口，而非预测所有未来
遗留代码往往靠“改if-else”或“加switch分支”应对新需求，导致逻辑越来越臃肿。OCP不是要求你提前设计插件体系，而是当发现某段逻辑被反复修改（比如支付方式从仅支持支付宝，到加微信，再到加银联），就该意识到这是个“变化点”。此时引入策略模式或简单工厂，把新增支付方式封装为独立实现，主流程只依赖抽象接口。
- 不必一上来就抽象出10个接口——从最近一次修改引发的重复代码**入手，例如三次新增校验规则都改了同一段if链，那就提取为Rule接口+多个RuleImpl
- 用“临时注释标记法”：在每次修改处加// TODO: extract as [Strategy/Policy]，积累3次后集中重构
- OCP的收益不在第一天，而在第5次需求变更时——你不再 grep 全局改代码，而只是加一个类、注册一下
里氏替换原则（LSP）：警惕“伪继承”带来的隐性破坏
很多遗留系统存在大量继承滥用：子类重写父类方法却改变契约（如父类返回非空List，子类返回null）；或父类方法依赖未声明的子类状态。这类代码看似能跑，但一旦做单元测试或引入Mock，立刻暴露脆弱性。LSP是重构中重要的“安全检查哨”。
- 重构前先运行现有测试，特别关注父类测试在子类实例上是否仍通过**
- 若子类重写了父类方法且逻辑差异大，问自己：这个子类还能被当作父类安全使用吗？如果答案是否定的，继承关系大概率错了，应改为组合
- 对已有继承树，可用“契约测试”兜底：为基类定义一组输入输出断言，强制所有子类实现相同行为
接口隔离原则（ISP）与依赖倒置原则（DIP）：协同降低“牵一发而动全身”的风险
遗留代码中常见“大接口”（如UserService包含user、role、permission、login所有方法），导致改登录逻辑要测全部用户功能。ISP建议按调用方视角拆小接口（如LoginService、UserQueryService）。而DIP则推动将这些接口放在核心模块，具体实现放在外层——这样业务逻辑不依赖数据库框架或HTTP客户端细节。
- 从最常被Mock的类**开始提炼接口（如DAO、第三方SDK包装类），它们天然符合ISP诉求
- DIP落地不需重写整个架构：先让Service依赖自定义的XXXClient接口，再让Config类注入具体实现（哪怕还是老的MyBatisMapper）
- 接口命名聚焦“做什么”，而非“谁来做”——UserRepository 比 MyBatisUserDao 更符合DIP精神
把SOLID当成手术刀，而不是蓝图。它不能告诉你哪行代码该删，但能帮你识别“这里正在腐化”；它不会自动生成新架构，但会在你每次想“快速修个bug”时，轻轻提醒：这个补丁，会不会让下一次修改更痛。
