遵循开闭原则：Open-Closed Principle，简称 OCP。定义为：软件实体应该对扩展开放，对修改关闭。

本文的目的是以电商场景为例，帮助初学者快速、简单地理解并记住责任链模式和策略模式，并将其融入实际开发当中。

责任链模式

定义

将多个请求处理者连接成一条处理链，使请求沿着这条链依次传递，直到某个处理者对其进行处理，或者经过所有处理者。责任链模式使请求的发送者与接收者解耦，并允许动态调整请求的处理流程。

常见场景——电商价格计算

在电商场景下，一个商品的价格计算往往不是简单的“单价 × 数量”，而是会涉及会员折扣、优惠券等复杂规则。

如果把所有规则都集中在一个方法中，会有如下缺点：

1. 方法代码行数过长，不易阅读。

2. 当部分规则发生变更时，不易定位和修改。

3. 每次新增或调整规则，都可能需要改动原有业务代码。

因此，引入责任链模式是比较合适的。

我们可以将一段很长的价格计算代码，拆分为一个个独立的处理节点。当规则发生变更时，可以快速定位并修改对应的规则节点；当出现新的规则时，也可以通过增加新的节点完成扩展，尽量避免修改原有的价格计算逻辑。

举例：

原价格计算流程：

单价 × 数量 -> 优惠券 -> 会员折扣

现在新增一个需求：添加长租优惠。

我们可以新增长租优惠节点，并将该节点插入原价格计算流程。

新价格计算流程：

单价 × 数量 -> 长租优惠 -> 优惠券 -> 会员折扣

原来的优惠券节点和会员折扣节点不需要发生变化，只需要增加新的长租优惠节点，并调整责任链的节点配置或执行顺序。

这体现了开闭原则：新增功能时，通过扩展新的处理节点实现，而不是直接修改原有的核心业务逻辑。

策略模式

定义

《设计模式》中如此定义：

Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

翻译为：

定义一系列算法，将每个算法分别封装起来，并使它们可以相互替换。策略模式使算法能够独立于使用它的客户端而发生变化。

常见场景——优惠券设计

在电商场景下，优惠券是常见的业务模块。

优惠券的类型非常丰富，例如满减券、抵扣券、折扣券、次卡等。不同类型的优惠券，其价格计算方式也不相同。

如果直接使用大量的 if-else 判断优惠券类型，随着优惠券类型不断增加，代码也会不断膨胀，显然不利于后续维护和扩展。

这时可以引入策略模式，将不同类型的优惠券计算算法分别封装起来，由程序根据优惠券类型选择对应的计算策略。

例如：

• 满减券使用满减策略；

• 折扣券使用折扣策略；

• 抵扣券使用固定金额抵扣策略；

• 次卡使用次卡计算策略。

需要注意的是，不是每一张优惠券都需要对应一个策略。

例如，“满100减10”和“满200减30”都可以使用同一个满减策略，只是优惠门槛和优惠金额等参数不同。只有计算方式真正不同时，才需要定义不同的策略。

对于上游开发者来说，他们不需要关心优惠券内部的具体实现逻辑，只需要传入优惠券 ID。

优惠券模块根据优惠券 ID 查询优惠券的类型和相关参数，再选择对应的优惠券策略完成价格计算。

这样可以避免价格计算业务随着优惠券计算规则的变化而频繁修改。

价格计算业务仍然可以按照以下流水线执行：

单价 × 数量 -> 长租优惠 -> 优惠券 -> 会员折扣

其中，责任链模式负责组织整个价格计算流程；策略模式负责在优惠券节点内部选择具体的优惠券计算方式。

简单来说：

责任链模式关注的是一个请求需要依次经过哪些处理节点。

策略模式关注的是完成同一个功能时，应该选择哪一种具体算法。