基于odoo17的设计模式详解---构建模式

大家好，我是你的Odoo技术伙伴。在Odoo开发中，创建一个简单的记录可能只需要一行 self.env['res.partner'].create({'name': 'New Partner'})。但如果我们要创建一个复杂的对象，比如一个包含了特定上下文、具有多个可选配置、并且需要执行一系列关联操作的销售订单，传统的create()方法可能会变得非常臃肿和难以阅读。

为了解决这个问题，软件设计领域提出了构建者模式（Builder Pattern）。今天，我们将深入探讨这一模式，并揭示Odoo是如何通过其独特的API设计，特别是链式调用（Method Chaining），将构建者模式的思想融入日常开发，帮助我们以一种更清晰、更灵活的方式来构造和配置对象。

一、什么是构建者模式？

让我们先从一个现实世界的例子开始：定制一台电脑。

当你去电脑品牌的官网定制一台电脑时，你不会看到一个包含所有可能配置（CPU、内存、硬盘、显卡…）的、拥有几十个参数的巨大表单。相反，你会经历一个分步的过程：

选择基础型号（产品）。
第一步：选择CPU。
第二步：选择内存大小。
第三步：选择硬盘类型和容量。
…
最后一步：确认配置并下单（生成最终产品）。

这个过程就是构建者模式的体现：

产品（Product）: 最终配置好的那台电脑。
构建者（Builder）: 官网的配置页面。它提供了一系列分步设置的方法（selectCPU(), selectRAM()），并内部维护着正在构建的电脑配置。
指挥者（Director） (可选): 可能是一个“推荐配置”按钮，它会按照预设的顺序调用构建者的各个方法，来快速生成一个“游戏玩家”或“办公文员”套餐。

构建者模式的核心思想是：将一个复杂对象的构建过程与其表示相分离，使得同样的构建过程可以创建不同的表示。它特别适用于当一个对象的创建需要多个步骤，或者其构造函数参数过多时。

二、Odoo中的构建者思想：链式调用与上下文

在Odoo中，你很少会需要自己去创建一个ComputerBuilder这样的类。Odoo的ORM和API设计，尤其是**记录集（Recordset）**的链式调用能力，天然地扮演了构建者的角色。

在Odoo中，记录集自身就是构建者，而其上的方法就是构建者的步骤。

经典案例：搜索查询的构建

Odoo的search()方法是构建者模式最直观的应用之一。虽然它看起来只是一行调用，但其返回的记录集可以被看作是一个“查询构建者”的结果，这个构建者可以被进一步配置。

传统的search()调用：

partners = self.env['res.partner'].search([('is_company', '=', True), ('country_id', '=', 'US')],order='name asc',limit=10,offset=5
)

这里，search()方法的多个参数扮演了配置步骤的角色。但更强大的构建者思想体现在链式调用上。

让我们想象一个更“构建者风格”的查询API（这并非Odoo原生API，仅为说明思想）：

# 这是一个假设的、更纯粹的Builder风格API
query_builder = self.env['res.partner'].builder() # 1. 获取构建者partners = query_builder.where([('is_company', '=', True)]) \.where([('country_id', '=', 'US')]) \.order_by('name asc') \.limit(10) \.offset(5) \.execute() # 2. 执行构建，返回产品

虽然Odoo没有提供这样的builder()方法，但它的ORM通过返回self（即记录集本身） 的方法，实现了类似的效果。

记录集操作的链式调用

Odoo的记录集方法，如filtered(), sorted(), with_context(), with_company()等，都返回一个新的、被修改过的记录集实例。这使得我们可以将它们链接起来，一步步地“构建”出我们最终想要操作的目标数据集。

场景：获取美国的所有公司客户，按名称排序，并以管理员权限（忽略记录规则）读取他们的邮箱。

# 1. 初始产品：所有伙伴的记录集
all_partners = self.env['res.partner'].search([])# 2. 开始分步构建
final_partners_to_process = all_partners \.filtered(lambda p: p.is_company and p.country_id.code == 'US') \.sorted(key=lambda p: p.name) \.sudo() # 以超级用户权限构建下一步的操作环境# 3. 获取最终结果（表示）
emails = final_partners_to_process.mapped('email')

代码解读:

all_partners: 我们的基础“原材料”。
.filtered(...): 第一步，过滤出公司和国家。返回一个新的、过滤后的记录集。
.sorted(...): 第二步，对上一步的结果进行排序。返回一个新的、排好序的记录集。
.sudo(): 第三步，为下一步操作切换用户上下文。返回一个新的、具有sudo权限的记录集。
final_partners_to_process: 这 Risk Management，这就是我们通过构建者模式，一步步构造出来的“待处理对象”。
.mapped('email'): 最后，我们从这个构造好的对象中提取出我们想要的数据（表示）。

每一个链式调用，都像是在定制电脑的流程中完成了一个配置步骤。这种方式比将所有逻辑都塞进一个复杂的search()或一个巨大的循环中，要清晰得多。

`with_context()`: 构建者的“环境配置”

with_context()方法是Odoo中构建者模式思想的又一绝佳体现。它允许你为一个即将进行的操作，临时构建一个特定的上下文环境，而不影响全局状态。

场景：以英文环境创建一张发票，无论当前用户的语言是什么。

# 1. 获取一个基础的“发票创建者”（即模型代理）
InvoiceBuilder = self.env['account.move']# 2. 使用 with_context() 来配置构建环境
InvoiceBuilderWithLang = InvoiceBuilder.with_context(lang='en_US')# 3. 在配置好的环境中，执行创建操作
new_invoice = InvoiceBuilderWithLang.create({'partner_id': some_partner.id,'move_type': 'out_invoice',
})
# 这张发票中的默认描述、税名等都会是英文的。

在这里，with_context()方法并没有改变InvoiceBuilder本身，而是返回了一个新的、携带了特定上下文的代理对象（构建者）。这使得构建过程更加灵活和安全。with_company()和with_user()也是同理。

四、优势与适用场景

优势

代码可读性强: 分步的、链式的调用让复杂的构建逻辑一目了然。
灵活性高: 客户端可以根据需要，自由组合构建步骤，或者只执行, 其中几步。
封装性好: 将复杂的构建逻辑封装在构建步骤（方法）中，使得客户端代码更加简洁。
支持不可变性: 像with_context这样的方法返回的是新对象，保证了原始构建者（模型代理）的不可变性，更加安全。

何时应用构建者思想？

在你的自定义模块中，当你需要设计一个方法来执行一个多步骤、多配置的复杂操作时，就可以借鉴构建者模式：

设计返回self的方法: 如果你的方法主要是为了配置或修改一个对象的状态，并希望支持链式调用，那么让它返回self（或一个新的记录集实例）。
提供配置方法: 与其设计一个有十几个参数的“上帝方法”，不如将其拆分为多个配置方法和一个最终的执行方法。

示例：一个自定义的报告生成器

class MyReportGenerator(models.AbstractModel):_name = 'my.report.generator'def new(self, records):self.records = recordsself.config = {}return self # 返回自身，支持链式调用def with_header(self, header_text):self.config['header'] = header_textreturn selfdef include_details(self, detailed=True):self.config['detailed'] = detailedreturn selfdef generate(self):# ... 根据 self.records 和 self.config 生成报告 ...return report_data# 使用
report_data = self.env['my.report.generator'] \.new(some_records) \.with_header("My Custom Report") \.include_details(True) \.generate()