基于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()