SOLID原则：SOLID实践案例

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

重构前问题

“如意食府”的后厨，活脱脱一盘意大利面：王大厨既是切配、又是炉头，还兼着收银和进货。他不在时，帮工小张找不到咸菜坛子，小李摸不清红烧肉的火候。代码界的“面条代码”就是这般光景——一个OrderService类里，订单校验、价格计算、库存扣减、支付对接、短信通知全搅在一起，方法动辄几百行，牵一发动全身。

改动为什么这么可怕？因为耦合。耦合就是模块之间纠缠的“人情债”。在餐厅里，收银台要等后厨出菜，后厨要等采购到位，谁都离不开谁，任何一环出问题，整条线瘫痪。代码里，支付逻辑改一个字段名，库存模块跟着编译失败；想为下单流程写个单元测试，却发现得连着真实数据库、真发短信、真调第三方支付，跑一次测试比做一桌菜还慢。

改造前，这家餐厅的“耦合账单”触目惊心：每个模块平均背负近两条依赖边。要改变现状，第一步就是拆分工位——这正是下一节要做的。

单一职责拆分

小王的改造方案第一刀，就是给后厨立规矩：切配师傅只负责把菜切好，炉头师傅只负责炒制，凉菜间、甜品台、收银台各管一摊。每个人都有一份清晰的“岗位说明书”，谁也不会把手伸进别人的锅里。这就是单一职责原则（SRP）——一个类应该只有一个变化的原因。

落到订单系统上，就是把臃肿的OrderService按职责劈开：OrderValidator只管校验订单合法性，PriceCalculator只算价钱，StockManager只动库存，PaymentProcessor只对接支付，NotificationService只发通知。每个类只有一个“老板”——一个引起它变更的业务方。改价格规则时，只有PriceCalculator需要动，支付和库存的代码原地不动。

切配、炒菜、收银各归其位后，厨房的混乱立刻消停了一半。但新问题来了：菜单要加新菜，总不能把厨房拆了重盖吧？这就是下一节开闭原则的用武之地。

开闭原则扩展

加新菜时，小王立了新规矩：后厨主流程不许改，新菜只需加一本新菜谱。炉头师傅照着“菜谱”做菜，他不需要知道每道菜的细节，新菜谱增加到架子上去就行。这就是开闭原则（OCP）——对扩展开放，对修改关闭。

代码世界里的“菜谱”，就是策略模式。订单系统的PaymentProcessor不再用 if-else 判断支付类型，而是依赖一个PaymentGateway接口，支付宝、微信支付、数字人民币都实现这个接口。要接一款新支付，只需新增一个实现类，原有的支付调度逻辑一行不改。主厨流程稳定如山，新菜谱源源不断上架。

有了“菜谱机制”，新支付两小时就能上线。但这里藏着一个隐患：新换的支付宝实现，会不会悄悄改变支付的行为？比如该抛异常时返回了 null。下一节，里氏替换原则来给替换兜底。

里氏替换保障

王大厨有个怪癖：红烧肉只用“李记酱油”。有一天李记断货，采购擅自换了“张记酱油”，结果色泽淡了、味道偏甜，老顾客一尝就皱眉。里氏替换原则（LSP）说的就是这件事：任何替换父类/接口实现的地方，程序对外表现出的行为契约必须保持不变。换酱油可以，但“浓油赤酱”的出品标准不能变。

在支付策略里，PaymentGateway接口定义了契约：pay(orderId, amount) 要么成功、要么抛出约定的异常。如果某个实现类图省事，失败时返回 null，上层拿到 null 直接空指针崩溃，这就是破坏契约。要守住契约，靠的是行为测试——把支付策略放进自动化测试里，验证每个实现类在成功/失败/超时三种场景下表现一致，就像让老顾客盲测酱油，尝不出区别才算过关。

替换有了保障，但接口设计还有个问题：客人点菜，不能把后厨所有内部流程都摊在菜单上。下一节，接口隔离来精简“菜单”。

接口隔离设计

如意食府改造后，菜单焕然一新：正面只有“下单、取消、查询”三个大字，那些“后厨备货流程”“供应商对账明细”统统不印给客人看。接口隔离原则（ISP）就是这个道理：客户端不应该被迫依赖它根本用不到的接口方法。胖接口就像一张写满后厨机密的菜单，让点菜的客人眼花缭乱。

订单系统里，如果OrderService把所有方法塞进一个大接口，支付模块只想调用pay()，却被强制看到了refund()、ship()、audit()一堆方法签名。代码层面，改动这些无关方法会触发支付模块重新编译；认知层面，读代码的人被噪音干扰。解法是拆成Orderable（下单）、Payable（支付）、Refundable（退款）等瘦接口，每个客户端只依赖自己那一个小菜单。

菜单瘦身之后，客人点单清爽了，后厨也松了口气。但还有一个最深层的结构问题：后厨和供应商怎么打交道？下一节，依赖反转给出答案。

依赖反转仓储

改造前，采购员每天跟具体供货商打电话，李记酱油一断档，后厨就停摆。小王定下规矩：采购面向“食材质量标准”下单，谁家的酱油达到标准就用谁家。后厨不再依赖具体供货商，而是依赖抽象标准；供货商反过来要向标准看齐。这就是依赖倒置原则（DIP）——高层模块不依赖低层模块，两者都依赖抽象。

对应到代码，OrderService不再直接 new 一个 MysqlOrderRepository，而是依赖OrderRepository接口。数据库从 MySQL 换成 MongoDB，只需新增一个实现类，再通过依赖注入把实现塞给业务层。仓储模式是 DIP 的经典落地：它把“订单数据存取”抽象成接口，业务层面向仓库接口编程，至于仓库背后是 MySQL、Oracle 还是内存，业务层一概不知。

现在，整个后厨的骨架焕然一新。但小王还有最后一件事要做：把改造前后的数据摆上桌，让老父亲看到钱花得值。

重构效果量化

改造满一个月，小王亮出成绩单：翻台率提升 40%，新菜上线时间从一周缩到半小时，新来的帮工一天就能上岗。光说感受不算数，数据才能服人。代码层面同样要量化：耦合度从 1.8 降到 0.6，单元测试覆盖率从 15% 冲到 80%，新增一种支付方式的工时从 3 天砍到 2 小时。

这些数字背后是可测试性的飞跃。重构前，测一次下单要连数据库、真发短信、真调支付，测试跑一次要十分钟；重构后，支付、短信都替换成测试替身，一条用例毫秒级跑完，CI 流水线几分钟内反馈全量结果。圈复杂度也大幅下降，每个类一眼就能看懂。

老父亲看着数据，终于点了头：SOLID 不是墙上的口号，而是能让餐厅脱胎换骨的菜谱。与其在面条代码里继续挣扎，不如从今天开始，切下第一刀。

AI 应用场景

Python 演示

from abc import ABC, abstractmethod class PaymentGateway(ABC):    """支付网关抽象：后厨的'菜谱标准'"""     @abstractmethod    def pay(self, order_id, amount):        """按契约执行支付，成功返回字符串，失败抛异常""" class Alipay(PaymentGateway):    def pay(self, order_id, amount):        return "支付宝支付 {} 元，订单 {}".format(amount, order_id) class WeChatPay(PaymentGateway):    def pay(self, order_id, amount):        return "微信支付 {} 元，订单 {}".format(amount, order_id) class PriceCalculator:    """单一职责：只负责算钱"""     def calc(self, amount, discount=1.0):        return round(amount * discount, 2) class OrderProcessor:    """依赖倒置：面向 PaymentGateway 接口编程"""     def __init__(self, gateway, calculator=None):        self.gateway = gateway        self.calculator = calculator or PriceCalculator()     def process(self, order_id, amount, discount=1.0):        final = self.calculator.calc(amount, discount)        return self.gateway.pay(order_id, final) if __name__ == "__main__":    proc = OrderProcessor(Alipay())    print(proc.process("A001", 100, 0.9))    proc2 = OrderProcessor(WeChatPay())    print(proc2.process("A002", 200, 0.8))

1. class PaymentGateway(ABC)用抽象基类定义“菜谱标准”，这是依赖倒置的锚点。
2. def __init__(self, gateway, calculator=None)构造函数注入依赖，替代到处 new，让替换变得丝滑。
3. proc = OrderProcessor(Alipay())想换微信支付？只改这一行注入即可，主流程一行不动。
4. self.calculator = calculator or PriceCalculator()默认提供一个实现，兼顾开闭与易用性。
5. final = self.calculator.calc(amount, discount)价格计算被隔离在独立模块，测试时单独精算。

常见误区

面试题