大家好，我是你的Odoo技术伙伴。想象一下，我们有一个复杂的对象结构，比如一个由不同类型的订单行（销售行、折扣行、备注行）组成的销售订单。现在，我们需要对这个结构执行一些新的操作，比如：

生成一份详细的PDF报价单。
将其数据导出为一种特殊的XML格式，以对接外部系统。
计算其中所有“实体产品”行的总重量。

如果我们将这些操作方法直接添加到订单行和订单的模型类中，会导致这些模型类越来越臃肿，违反了单一职责原则。更糟糕的是，每当需要一个新的操作时，我们都得去修改这些核心的业务模型。

为了解决这个问题，软件设计领域引入了一种非常精巧的模式——访问者模式（Visitor Pattern）。

一、什么是访问者模式？

让我们用一个旅行的例子来理解它：

对象结构（Object Structure）: 一个城市，里面有各种不同类型的景点，如博物馆（Element A）、公园（Element B）、历史遗迹（Element C）。
访问者（Visitor）: 你，一个旅行者。

现在，不同类型的旅行者（访问者）来到这个城市，他们对景点的“操作”是不同的：

一个历史学家（Visitor 1）:
- 在博物馆，他会花大量时间研究文物（visit_museum()）。
- 在公园，他可能只是匆匆走过（visit_park()）。
- 在历史遗迹，他会进行详细的考古笔记（visit_historic_site()）。
一个摄影师（Visitor 2）:
- 在博物馆，他可能只对建筑光影感兴趣。
- 在公园，他会寻找最佳的自然风光拍摄角度。
- 在历史遗迹，他会专注于捕捉残垣断壁的沧桑感。

关键在于：

景点（对象结构）是稳定的：城市不会因为来了一个摄影师就改变自己的结构。
操作是多变的: 我们可以随时“派遣”一个新的访问者（比如一个美食家）来对这个城市进行全新的操作（寻找美食）。
双重分派（Double Dispatch）: 当一个访问者访问一个景点时，最终执行的动作由“访问者的类型”和“景点的类型”两者共同决定。

转换成软件设计的语言：

访问者模式表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下，定义作用于这些元素的新操作。

二、Odoo中的访问者模式：报表引擎与数据处理

在Odoo中，访问者模式的思想主要体现在那些需要处理异构对象结构（heterogeneous object structures）并对其执行复杂操作的场景中，最典型的就是报表引擎和数据序列化/导出。

场景：生成销售订单的PDF报表

Odoo的报表系统（基于QWeb引擎）是访问者模式的一个绝佳范例。

对象结构（Object Structure）: sale.order记录及其关联的sale.order.line记录集。这个记录集是异构的，因为订单行可能是普通的产品行，也可能是用于分组的“章节（Section）”行或纯文本的“备注（Note）”行。
元素（Elements）: 每个sale.order.line记录。
访问者（Visitor）: QWeb报表模板（.xml文件）。这个模板本身就是一个包含了“如何处理（渲染）”不同类型元素逻辑的“访问者”。

让我们看一个简化的QWeb模板：

<!-- a_module/reports/sale_order_report.xml -->
<template id="report_saleorder_document"><t t-call="web.html_container"><t t-foreach="docs" t-as="doc"> <!-- 'doc' is a sale.order record --><!-- ... 报表头 ... --><table><thead>...</thead><tbody><!-- 遍历对象结构中的每个元素 (order_line) --><t t-foreach="doc.order_line" t-as="line"><!-- “双重分派”：根据元素的类型，执行不同的访问/渲染逻辑 --><!-- 访问者对“章节”类型的元素的操作 --><tr t-if="line.display_type == 'line_section'"><td colspan="99"><strong><span t-field="line.name"/></strong></td></tr><!-- 访问者对“备注”类型的元素的操作 --><tr t-if="line.display_type == 'line_note'"><td colspan="99"><span t-field="line.name"/></td></tr><!-- 访问者对“普通产品”类型的元素的操作 --><tr t-if="not line.display_type"><td><span t-field="line.product_id.name"/></td><td><span t-field="line.product_uom_qty"/></td><!-- ... 其他列 ... --></tr></t></tbody></table></t></t>
</template>

这个过程如何体现访问者模式？

稳定的对象结构: sale.order和sale.order.line的模型定义是稳定的。我们为了生成一份新的报表样式，完全不需要去修改它们的Python代码。
分离的操作: 报表的渲染逻辑（如何将一个订单行显示在PDF上）被完全封装在了QWeb模板（访问者）中，与模型的核心业务逻辑分离。
轻松添加新操作: 如果我们想创建一个新的、完全不同格式的报表（比如一个简化的内部成本核算表），我们只需要创建一个新的QWeb模板（一个新的访问者），而无需触碰任何Python模型。这个新访问者可以有自己的一套全新的逻辑来“访问”和“解读”sale.order和sale.order.line。
双重分派的体现: t-if语句的判断 line.display_type == '...'，实际上就是在模拟双重分派。QWeb引擎（作为调用者）将模板（访问者）应用于line（元素），而最终的渲染结果取决于line的类型。

另一个例子：数据导出/序列化

当我们需要将Odoo中的一个复杂对象（如包含多层嵌套的物料清单BoM）导出为一个特定的JSON或XML格式时，也可以应用访问者模式。

我们可以创建一个BomJsonVisitor类，它有visit_bom(bom)和visit_bom_line(line)等方法。然后我们写一个遍历函数，它接受一个BoM对象和一个Visitor对象，递归地遍历BoM树，并在每个节点上调用visitor.visit_...(node)。

这样，如果我们将来需要导出为XML，只需再创建一个BomXmlVisitor即可，而核心的遍历逻辑和BoM模型都无需改动。

三、优势与适用场景

优势

符合开闭原则: 可以在不修改现有对象结构的情况下，轻松地添加新的操作。这对于像Odoo这样需要高度可扩展性的系统来说至关重要。
集中相关操作: 将一个特定操作（如PDF渲染）的所有相关逻辑都集中在一个访问者类中，而不是分散在各个元素类里，使得代码更加内聚。
操作复杂结构: 访问者模式非常适合用于处理复杂的、由不同类型对象组成的树形或复合结构。

注意事项

破坏封装性（潜在风险）: 为了让访问者能够执行操作，元素类通常需要暴露一些其内部状态的接口，这在某种程度上可能会破坏其封装性。
对象结构难以修改: 访问者模式的优点是易于添加新操作，但其代价是难以添加新的元素类型。如果你的对象结构（比如sale.order.line的display_type）经常需要增加新的类型，那么每个已有的访问者（QWeb模板）都需要被修改以支持这个新类型，这会违反开闭原则。

因此，访问者模式最适用于：对象结构相对稳定，但需要频繁地为其定义新操作的场景。 Odoo的报表系统正是这样一个完美的场景。