大家好，我是你的Odoo技术伙伴。在企业应用中，业务规则常常是多变的。比如，计算运费的方式可能根据不同的快递公司、目的地、包裹重量而有天壤之别；一个产品的定价策略可能包括固定价格、基于成本加成、根据客户等级折扣等多种算法。
如果用一堆if/else语句来处理这些可变的规则，代码很快会变成一团乱麻，每次新增或修改一个规则，都像是在雷区里排雷。为了优雅地解决这个问题，软件设计领域引入了策略模式（Strategy Pattern）。
今天，我们就来深入探讨这一模式，并揭示Odoo是如何利用它来构建灵活、可配置、易于扩展的业务功能的。
一、什么是策略模式？
让我们从一个简单的生活场景开始：周末出行。
假设你周末要从家去市中心，你有多种出行方式可供选择：
策略A：坐地铁。优点是准时、不受堵车影响，但可能需要走路去地铁站。
策略B：打出租车。优点是点对点，非常方便，但成本高且可能遇到堵车。
策略C：骑共享单车。优点是灵活、锻炼身体，但受天气和距离限制。
你（上下文 Context）: 出行的人，你的目标是到达市中心。
出行方式（策略 Strategy）: 地铁、出租车、单车，它们都是为了达成“到达市中心”这个目标的不同算法。
你可以根据当天的情况（天气、预算、时间紧迫性）动态地选择其中一种策略来执行。重要的是，无论你选择哪种策略，你作为“出行者”的角色没有变，你的目标也没有变。
转换成软件设计的语言：
策略模式定义了一系列的算法（策略），并将每一个算法封装起来，使它们可以相互替换。它让算法的变化独立于使用算法的客户端。
二、Odoo中的策略模式：可配置的业务逻辑
在Odoo中，策略模式的应用非常广泛，它通常不是以教科书式的Strategy接口和具体实现类出现，而是通过更符合Odoo架构的方式来实现，其核心特征是：将一个业务操作的具体实现，委托给一个可配置的、可替换的组件。
经典案例一：产品的可用性计算 (availability)
Odoo库存模块中，产品表单上显示的“预计可用数量”（Forecasted Quantity）就是一个策略模式的绝佳范例。它的计算方式可以非常复杂。
- 上下文（Context）: product.product 或 product.template 模型，它需要知道自己的“可用数量”。
- 策略（Strategies）:
- 策略A (默认): 可用数量 = 库存数量 + 预计入库 - 预计出库。
- 策略B (自定义): 某个公司可能认为，可用数量还应该减去“安全库存”。
- 策略C (更复杂): 另一个公司可能需要考虑“在制品数量”或“待质检数量”。
Odoo如何实现这种可配置性？通常是通过**重写（override）**核心的计算方法。在这里，不同的模块（策略）可以重写同一个方法，来提供不同的计算“算法”。
# 基础策略 (在 stock 模块中)
class Product(models.Model):
_inherit = 'product.product'
def _compute_quantities(self):
# ...
# 默认算法：(in + done) - out
res = self._compute_quantities_dict(self._context.get('lot_id'), ...)
for product in self:
product.qty_available = res[product.id]['qty_available']
product.virtual_available = res[product.id]['virtual_available']
# ...
# 扩展策略 (在一个自定义模块 my_module 中)
class ProductWithSafetyStock(models.Model):
_inherit = 'product.product'
safety_stock = fields.Float('Safety Stock')
def _compute_quantities(self):
# 首先，调用原始策略获取基础计算结果
super(ProductWithSafetyStock, self)._compute_quantities()
# 然后，应用自己的策略来调整结果
for product in self:
# 新的算法：可用数量 = (原始可用数量) - 安全库存
product.virtual_available -= product.safety_stock
在这个例子中，安装my_module就相当于为系统“切换”到了一个新的可用性计算策略。客户端（任何访问product.virtual_available字段的地方）无需任何改变，它得到的已经是应用了新策略之后的结果。
经典案例二：开票策略 (invoice_policy)
销售订单 (sale.order) 上的“开票策略”字段是另一个直观的策略模式应用。
- 上下文（Context）:
sale.order模型，它需要在某个时机被转换成发票。 - 策略接口（Strategy Interface）: “创建发票”这个动作。
- 具体策略（Concrete Strategies）:
invoice_policy字段的选项：- order (开具订单全额发票): 点击“创建发票”时，会基于订单总额生成一张发票。
- delivery (开具已发货数量的发票): 点击“创建发票”时，系统会检查已发货的数量，并只为这部分开具发票。
实现方式:
在sale.order的_create_invoices()方法（这是一个外观方法）内部，会检查self.invoice_policy的值，并根据这个值，执行不同的逻辑分支来准备发票行。
# 伪代码，简化自 sale.order._create_invoices()
def _create_invoices(self, grouped=False, final=False):
# ...
for order in self:
# 上下文根据其配置的策略，选择不同的算法
if order.invoice_policy == 'delivery':
# 执行“按已发货数量”的算法来准备发票行
invoice_vals = order._prepare_invoice_for_delivery()
else: # order.invoice_policy == 'order'
# 执行“按订单数量”的算法来准备发票行
invoice_vals = order._prepare_invoice_for_order()
# ... 创建发票 ...
这里，_prepare_invoice_for_delivery()和_prepare_invoice_for_order()就是两个被封装起来的具体策略实现。_create_invoices()方法作为上下文，根据配置动态地选择并执行它们。
三、策略模式与职责链模式的区别
在Odoo中，通过重写super()方法来实现的逻辑扩展，有时看起来既像策略模式，又像职责链模式。它们的区别在于意图：
- 职责链模式：意图是让多个处理者依次对一个请求进行处理或增强。重点在于“链式”和“传递”。每个处理者都贡献一部分，共同完成任务。
- 策略模式：意图是从多个可互换的算法中，选择一个来完成整个任务。重点在于“选择”和“替换”。策略之间是平行的，一次只用一个。
在_compute_quantities的例子中，它更偏向于职责链，因为super()被调用，新逻辑是在旧逻辑的基础上增强。而在invoice_policy的例子中，它更纯粹地体现了策略模式，因为系统根据配置，在多个算法分支中选择一个来执行。
四、优势与适用场景
优势
- 消除条件语句: 将复杂的if/else或switch结构替换为更清晰的、可插拔的策略对象/方法，提高了代码的可读性和可维护性。
- 符合开闭原则: 可以轻松地增加新的策略（比如一个新的开票策略或运费计算方式），而无需修改上下文（
sale.order）的代码。 - 算法复用: 策略可以被多个不同的上下文复用。
- 客户端解耦: 客户端（调用者）只与统一的接口交互，无需知道具体的策略实现细节。
何时应用策略模式？
在你的Odoo开发中，当你遇到以下情况时，应考虑使用策略模式：
- 一个业务操作有多种不同的实现方式，并且这些方式需要在运行时根据配置或条件进行选择。
- 你预见到未来可能会有新的实现方式加入。
- 你需要将一个算法的具体实现细节，从使用它的业务逻辑中分离出来。
- 你可以通过在模型上添加一个Selection字段来存储策略选择，然后在核心业务方法中根据该字段的值，调用不同的辅助方法（每个辅助方法封装一个策略）。
结论
策略模式是Odoo中实现业务灵活性和可扩展性的关键设计模式。它让我们能够将“做什么”（业务目标）和“怎么做”（具体算法）分离开来，使得系统能够从容应对多变的业务规则。
通过在模型上提供可配置的选项，并封装不同的业务算法，Odoo将策略模式的思想融入到了其核心设计之中。作为开发者，掌握并运用这一模式，将帮助我们构建出更加健壮、灵活，并且能够轻松适应未来变化的强大应用。