大家好，我是你的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的報表系統正是這樣一個完美的場景。
結論
訪問者模式是一種優雅的、用于實現功能與數據結構分離的設計模式。在Odoo中，它雖然不常以顯式的Visitor類出現，但其核心思想——將操作邏輯從被操作的對象中抽離出來——在QWeb報表引擎等模塊中得到了淋漓盡致的體現。
通過將渲染邏輯封裝在QWeb模板（訪問者）中，Odoo允許我們自由地為同一套穩定的數據模型（如sale.order）創建出無數種不同的視圖（報表），而無需對核心業務代碼進行任何侵入式修改。
作為Odoo開發者，理解訪問者模式，將幫助你更好地設計可擴展的數據處理和展現功能。當你遇到一個需求，需要對一個復雜的、穩定的對象結構進行多種不同的、未來可能還會增加的“解讀”或“操作”時，訪問者模式將為你提供一個強大而優雅的設計思路。
