SOLID原则：OCP开闭原则

可视化演示

对比展示OCP违反与遵守的差异，通过策略模式和装饰器模式演示扩展开放修改关闭的实现，点击按钮切换各设计模式视图

原则定义：一堵不开槽的墙

想象你是一位房东，房子已经租出去了。租客今天想装智能门锁，明天想换即热饮水机。聪明的做法是什么？是在装修时就留好标准插座，而不是每来一个新需求就把墙面凿开。1988 年，Bertrand Meyer 在《面向对象软件构造》中把这种智慧写进了软件工程：一个软件实体应当对扩展开放，对修改关闭。

“对扩展开放”，意思是新需求来临时，系统有能力容纳新增的行为；“对修改关闭”，指的是已有的、经过验证的代码不因新需求而被迫改动。两者合起来就是 OCP：用“加新零件”代替“拆旧零件”。违反 OCP 的典型场景是：支付模块里躺着一串 if-else，每接入一种新支付方式，就有人在这串分支里再添一处。第一次加没问题，第十次加时，谁也不敢保证没碰坏原有的转账逻辑——因为修改的是同一段被无数调用方依赖的代码。

反过来说，为什么“修改旧代码”如此危险？因为旧代码往往已被多个模块复用、被测试用例锁定、被线上流量验证。每改一次，回归风险的涟漪就向外扩散一圈。OCP 的价值，就是把这个“扩散半径”压缩到零：

所以，判断一段代码是否遵守 OCP，只需问一句：下一次需求到来时，我要不要回头改它？如果答案是“不用，加个新类就行”，那你就像那位提前留好插座的房东，墙面每一寸都安然无恙；如果答案是“又得去动那坨老逻辑”，说明插座留错了位置，或者压根没留。

抽象与多态：插座标准的诞生

墙上的插座为什么能接住千奇百怪的电器？因为国家统一了插脚标准——电压、频率、孔径，全都标准化。电器内部电路再复杂，插脚必须长成标准模样。这个“标准”，就是软件里的抽象：接口或抽象类。

抽象把“什么方法必须有”（接口契约）和“方法如何实现”（具体逻辑）分开。多态则让同一个调用点运行不同实现。比如定义一个 Payment 接口，声明 pay(amount) 方法；支付宝、微信、银行卡各自实现，但调用方眼里它们都是“一个能付钱的 Payment”。

正是这对组合支撑了 OCP。插座不认识具体电器，只认插脚标准；调用方不依赖具体实现类，只依赖抽象接口。于是，新增实现类不再触碰任何既有代码，只需“长成标准模样”就能被系统接纳。依赖关系从“调用方指向具体类”变成“调用方指向抽象、实现类也指向抽象”——这就是依赖抽象，也是多态背后的稳定关联：

只要你的电器插脚符合国标，插座永远不必认识电饭煲内部的加热管长什么样。软件亦然：只要实现类遵守接口契约，核心模块永远不必认识新来的支付策略内部长什么样。

策略模式：把扩展变成换插头

插座本身不产生任何功能，它的本事是“让不同的电器插上去就干活”——插上电水壶能烧水，插上充电器能充电。这就是策略模式（Strategy Pattern）的日常版本：定义一族策略接口，把可互换的算法各自封装成类，再由上下文（Context）持有并调用。

在支付场景中，策略模式把 if-else 的一锅乱炖彻底分解：PaymentStrategy 是“插座标准”，AlipayStrategy、WechatStrategy、BankCardStrategy 是插上去的“电器”，PaymentContext 是“墙上的插座”——它只负责持有当前策略、把支付请求委托出去。运行时想换支付方式？一行 setStrategy，就相当于拔下电水壶、插上充电器。

对比两种做法。传统 if-else 中，新增支付方式是“修改”：打开支付函数，找到分支，加一段，重新测试全部流程。策略模式下，新增支付方式是“扩展”：新建一个类实现策略接口，在注册表登记，所有调用方原封不动。改造前后的核心差异，可以用一句话概括——上下文对具体策略一无所知：

换电器不换插座，换策略不换上下文。策略模式把“变化”打包成一件件可拆卸的家电，让系统的扩展像插拔插头一样优雅。

工程落地：在变化点预埋插座

有经验的装修师傅会在厨房多留几个插座，但不会在吊顶上留一排用不上的五孔。工程落地的第一课就是：在需求真正变化之前，想清楚哪里可能装新电器——也就是“识别变化点”。

识别变化点有一套朴素的方法：找需求文档里“以后可能要支持”“目前先支持一种”之类的措辞；看代码里频繁被改动的函数；统计同一处 if-else 被追加过多少次。找到变化点后，第二步是“封装变化”——把会变的部分包进接口背后，让它与稳定部分隔离。支付方式在变，但“发起支付、等待结果、返回状态”的流程不变，所以把流程留在上下文，把变化交给策略。

落地时还需克制“最小扩展”：不为假设中的需求预埋豪华设计，而是让每个新需求都走“新增代码、零改旧码”的通道。假设今天要给支付系统加一种“数字人民币”支付，工作清单是这样的——新增一个类、注册一行配置、端侧传一个新策略名，全程没有一行旧代码被按下删除键：

好房东在装修时留足插座，好程序员在代码里留好扩展位。识别变化点、封装变化、最小扩展，这三板斧让“开”与“闭”从口号变成每天提交代码时的习惯。

稳定抽象指标：给设计验房

装修有验收标准：插座离地 30 厘米、承重墙不许开槽。软件设计也需要客观的“验房师”。Robert Martin 提出了一组度量：抽象程度 A、不稳定依赖 I 和主序列距离 D。

抽象程度 A 衡量一个组件里抽象类（含接口）占全部类的比例——A 越接近 1，组件越“抽象”。不稳定依赖 I 衡量组件被“拖下水”的程度：向外依赖越多、被内部依赖越少，I 越接近 1，组件就越容易因为别人的变化而震荡。两者合起来得到主序列距离 D——衡量组件距离“理想平衡线”的远近。抽象且稳定（A 大、I 小）的组件，才是 OCP 喜欢的“承重墙”：

用过这些指标，你就能像监理一样审视自己的模块：抽象度很高却没人依赖的接口，等于在杂物间里装了个豪华插座——中看不中用。指标不是教条，而是帮你在“抽象”与“稳定”之间找到平衡点的量尺。

权衡与边界：不是所有墙都要留孔

装修最忌讳两件事：插座留得太少，日后满屋插线板；插座留得太多，墙面千疮百孔。OCP 也有代价——每多一层抽象，就多一层间接调用，多一份理解成本。无脑给所有类加接口，等于在墙上装满了从未被使用的插座。

所以，成熟的设计者会先问三个问题：这个点真的会变吗？变化的频率有多高？修改一次旧代码代价有多大？三者相乘才是“抽象收益”。只有当收益大于成本时，抽象才值得做。这恰好呼应了 YAGNI（你不会需要它）原则：不要把宝押在想象中的需求上，而是让代码先简单、后进化。当第二个真实变化出现时，再抽出接口，做一次小步重构，成本最低也最安全：

真正的高手不是插座控，而是懂得在“留太多”和“留太少”之间拿捏分寸的装修师。OCP 不是口号式的“能抽象就抽象”，而是基于变化概率的工程决策——以及团队成员共同遵守的默契，比如在 Code Review 中约定：新增功能时，diff 里不许出现核心流程文件。

AI 应用场景

Python 演示

from abc import ABC, abstractmethod  class PaymentStrategy(ABC):    """支付策略接口：所有支付方式都要遵守的插脚标准"""     @abstractmethod    def pay(self, amount):        """执行支付并返回描述文本"""  class AlipayStrategy(PaymentStrategy):    def pay(self, amount):        return "支付宝支付 {:.2f} 元".format(amount)  class WechatStrategy(PaymentStrategy):    def pay(self, amount):        return "微信支付 {:.2f} 元".format(amount)  class BankCardStrategy(PaymentStrategy):    def pay(self, amount):        return "银行卡支付 {:.2f} 元".format(amount)  class CryptoStrategy(PaymentStrategy):    def pay(self, amount):        return "数字币支付 {:.2f} 元".format(amount)  class PaymentContext:    """支付上下文：墙上的插座，负责接住任意策略"""     _registry = {}     @classmethod    def register(cls, name, strategy_cls):        cls._registry[name] = strategy_cls     @classmethod    def new_strategy(cls, name):        if name not in cls._registry:            raise ValueError("未知支付方式: " + name)        return cls._registry[name]()     @classmethod    def create(cls, name):        return cls(cls.new_strategy(name))     def __init__(self, strategy):        self._strategy = strategy     def set_strategy(self, strategy):        self._strategy = strategy     def execute(self, amount):        return self._strategy.pay(amount)  def main():    PaymentContext.register("alipay", AlipayStrategy)    PaymentContext.register("wechat", WechatStrategy)    PaymentContext.register("bank", BankCardStrategy)     ctx = PaymentContext.create("alipay")    print(ctx.execute(199.0))     ctx.set_strategy(PaymentContext.new_strategy("wechat"))    print(ctx.execute(99.5))     # 新支付方式：只新增一个类 + 一行注册，旧代码零改动    PaymentContext.register("crypto", CryptoStrategy)    ctx.set_strategy(PaymentContext.new_strategy("crypto"))    print(ctx.execute(1.0))  if __name__ == "__main__":    main()

1. class PaymentStrategy(ABC):插座标准：声明所有支付方式必须具备的统一能力
2. @abstractmethod强制每个子类实现 pay，防止“插脚缺失”的电器混进来
3. PaymentContext._registry = {}注册表：记录“插头型号”与实现类的对应关系
4. def register(cls, name, strategy_cls)开放给外部的登记口，新策略只需在此报到
5. def new_strategy(cls, name)按名字创建策略，未知名字抛出异常，保护核心流程
6. def execute(self, amount)核心调用流程，永远只做一件事：委托给当前策略
7. ctx.set_strategy(PaymentContext.new_strategy("wechat"))运行时换插头，上下文零改动
8. PaymentContext.register("crypto", CryptoStrategy)这就是 OCP 的缩影：新增能力 = 一行注册

常见误区

面试题