大家好，我是你的Odoo技术伙伴。在Odoo的世界里，我们经常会遇到具有天然层级或“部分-整体”关系的数据结构。比如，一个会计科目表，其中每个科目可以是顶级科目，也可以是另一个科目的子科目；一个物料清单（BoM），其中一个成品由多个半成品组成，而每个半成品又可能由更基础的原材料组成。
如何才能一致地、透明地处理这些结构中的“单个对象”和“对象组合”？答案就是我们今天要深入探讨的——组合模式（Composite Pattern）。
一、什么是组合模式？
让我们先从一个大家都很熟悉的文件系统来理解它：
- 叶子节点（Leaf）: 一个文件（如
report.pdf）。它有自己的属性（大小、类型），但它不能再包含其他文件。 - 组合节点（Composite）: 一个文件夹（如
My Documents）。它也有自己的属性，但最重要的是，它可以包含其他文件（叶子节点）和文件夹（组合节点）。
组合模式的精髓在于：你希望能够以同样的方式对待单个文件和整个文件夹。比如，当你计算一个文件夹的大小时，你实际上是在递归地计算其下所有文件和子文件夹的大小总和。对于调用者来说，它只需要对顶层文件夹调用 calculate_size() 方法，而无需关心其内部是文件还是文件夹。
转换成软件设计的语言：
组合模式将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户端对单个对象（叶子）和组合对象（容器）的使用具有一致性。
二、Odoo中的组合模式：父子关系的天然体现
在Odoo中，组合模式的核心实现通常依赖于模型中的自引用关联字段（Self-referencing Relational Fields），最常见的是 Many2one 和 One2many 字段的组合。
- 组件（Component）: 模型的基类，定义了叶子和组合节点共有的接口（即模型的所有方法和字段）。
- 叶子节点（Leaf）: 一个没有子节点的记录，其
child_ids字段为空。 - 组合节点（Composite）: 一个拥有子节点的记录，其
child_ids字段不为空。
经典案例：会计科目表 (account.account)
Odoo的会计科目表是组合模式的教科书级范例。
模型定义
在 addons/account/models/account_account.py 中，我们可以找到类似这样的结构：
class AccountAccount(models.Model):
_name = 'account.account'
_parent_store = True # 开启父路径存储，优化层级查询
# ... 其他字段如 name, code ...
# 组合模式的核心：自引用关系
parent_id = fields.Many2one('account.account', string='Parent Account', ondelete='cascade')
child_ids = fields.One2many('account.account', 'parent_id', string='Child Accounts')
# 用于层级视图和查询优化
parent_path = fields.Char(index=True, unaccent=False)
# ...
结构解读
parent_id: 一个Many2one字段，指向同一个模型account.account。它定义了“我属于谁”。child_ids: 一个One2many字段，是parent_id的反向关系。它定义了“谁属于我”。- 通过这两个字段，
account.account的记录被组织成了一棵树。一个没有parent_id的科目就是树的根节点。
一致性操作的威力
组合模式最大的威力在于，你可以对树上的任何一个节点（无论是叶子还是组合节点）执行相同的操作。
场景：计算一个科目的总余额
假设我们需要一个方法来计算某个会计科目及其所有子孙科目的总余额。
class AccountAccount(models.Model):
_inherit = 'account.account'
balance = fields.Monetary(compute='_compute_balance', string='Balance')
def _compute_balance(self):
for account in self:
# 对于当前科目，我们首先计算它自己的余额 (不含子科目)
# 简化逻辑，实际更复杂
# res = self.env['account.move.line'].read_group(...)
current_balance = account._get_own_balance()
# 关键：递归地处理子节点
# 我们对所有子节点求和，而子节点内部的计算也是通过同样的方式
children_balance = sum(child.balance for child in account.child_ids)
account.balance = current_balance + children_balance
代码分析
- 统一接口:
_compute_balance方法对所有account.account实例都可用。 - 透明性: 当你调用
some_account.balance时，你无需关心some_account是一个没有子科目的“叶子”科目，还是一个包含庞大家族的“组合”科目。- 如果它是叶子节点，
account.child_ids为空，children_balance为 0，结果就是它自身的余额。 - 如果它是组合节点，它会计算自身的余额，并递归地加上所有子孙的余额总和。
- 如果它是叶子节点，
sum(child.balance ...)这一行代码完美地体现了组合模式的精髓：对组合对象的操作，被委托给了其所有子组件。
另一个案例：物料清单 (BoM)
mrp.bom（物料清单）和 mrp.bom.line（清单行）是另一个经典的“部分-整体”结构，也应用了组合模式的思想。一个 BoM 可以包含原材料（叶子），也可以包含其他半成品的 BoM（组合）。计算一个最终产品的总成本时，就需要递归地展开所有层级的 BoM，累加所有组件的成本。
三、Odoo中的视图层支持
Odoo 的前端视图也对组合模式提供了强大的原生支持，最典型的就是**树状视图（Tree View）**的层级显示。
当你为一个实现了父子关系的模型（如 account.account）创建一个树状视图时，Odoo 会自动识别出 child_ids 字段，并以可展开/折叠的层级结构来展示数据。
<record id="view_account_list" model="ir.ui.view">
<field name="name">account.account.list</field>
<field name="model">account.account</field>
<field name="arch" type="xml">
<!-- Odoo自动识别父子关系，无需特殊配置 -->
<tree>
<field name="display_name"/>
<field name="code"/>
<field name="balance" sum="Total Balance"/>
</tree>
</field>
</record>
用户可以在 UI 上直观地与这个树形结构交互，而这背后正是组合模式在数据层面的支撑。
四、优势与注意事项
优势
- 简化客户端代码: 客户端可以统一处理所有对象，无需用
if/else来区分叶子和组合节点。 - 易于添加新组件: 可以很容易地向组合中添加新的叶子或组合节点，而无需改动现有代码，符合开闭原则。
- 天然匹配层级结构: 对于任何具有层级关系的需求，组合模式都是首选的、最自然的建模方式。
注意事项
- 性能考量: 深度递归操作可能会带来性能问题。对于层级很深的树，一次性计算所有子孙节点的属性可能会很慢。Odoo 为此提供了
parent_path和_parent_store = True这样的优化机制，它将每个节点的完整父路径存储在一个字段中，使得可以通过高效的 SQLLIKE查询来一次性获取所有子孙节点，避免了多次递归查询。 - “过于透明”的风险: 让叶子节点也拥有添加/删除子节点的方法（即使是空实现）可能会让接口不够安全。Odoo 通过
One2many和Many2one的机制很好地处理了这一点，你不能为一个记录的child_ids添加一个已经有parent_id的记录，ORM 层会自动处理这种约束。
结论
组合模式是 Odoo 中用于表示和操作层级数据结构的核心设计模式。它通过模型中简单的自引用关系，结合递归的方法调用，实现了对复杂树形结构的优雅、统一处理。
从会计科目、产品分类、组织架构到物料清单，组合模式无处不在。理解它，意味着你掌握了在 Odoo 中构建任何“部分-整体”层级系统的钥匙。当你面对一个具有树形结构的需求时，请自信地使用 parent_id 和 child_ids，并用递归的思路来设计你的业务方法，组合模式将是你最坚实的后盾。
大家好，我是你的Odoo技术伙伴。在Odoo的世界里，我们经常会遇到具有天然层级或“部分-整体”关系的数据结构。比如，一个会计科目表，其中每个科目可以是顶级科目，也可以是另一个科目的子科目；一个物料清单（BoM），其中一个成品由多个半成品组成，而每个半成品又可能由更基础的原材料组成。
如何才能一致地、透明地处理这些结构中的“单个对象”和“对象组合”？答案就是我们今天要深入探讨的——组合模式（Composite Pattern）。
一、什么是组合模式？
让我们先从一个大家都很熟悉的文件系统来理解它：
- 叶子节点（Leaf）: 一个文件（如
report.pdf）。它有自己的属性（大小、类型），但它不能再包含其他文件。 - 组合节点（Composite）: 一个文件夹（如
My Documents）。它也有自己的属性，但最重要的是，它可以包含其他文件（叶子节点）和文件夹（组合节点）。
组合模式的精髓在于：你希望能够以同样的方式对待单个文件和整个文件夹。比如，当你计算一个文件夹的大小时，你实际上是在递归地计算其下所有文件和子文件夹的大小总和。对于调用者来说，它只需要对顶层文件夹调用 calculate_size() 方法，而无需关心其内部是文件还是文件夹。
转换成软件设计的语言：
组合模式将对象组合成树形结构以表示“部分-整体”的层次结构。它使得客户端对单个对象（叶子）和组合对象（容器）的使用具有一致性。
二、Odoo中的组合模式：父子关系的天然体现
在Odoo中，组合模式的核心实现通常依赖于模型中的自引用关联字段（Self-referencing Relational Fields），最常见的是 Many2one 和 One2many 字段的组合。
- 组件（Component）: 模型的基类，定义了叶子和组合节点共有的接口（即模型的所有方法和字段）。
- 叶子节点（Leaf）: 一个没有子节点的记录，其
child_ids字段为空。 - 组合节点（Composite）: 一个拥有子节点的记录，其
child_ids字段不为空。
经典案例：会计科目表 (account.account)
Odoo的会计科目表是组合模式的教科书级范例。
模型定义
在 addons/account/models/account_account.py 中，我们可以找到类似这样的结构：
class AccountAccount(models.Model):
_name = 'account.account'
_parent_store = True # 开启父路径存储，优化层级查询
# ... 其他字段如 name, code ...
# 组合模式的核心：自引用关系
parent_id = fields.Many2one('account.account', string='Parent Account', ondelete='cascade')
child_ids = fields.One2many('account.account', 'parent_id', string='Child Accounts')
# 用于层级视图和查询优化
parent_path = fields.Char(index=True, unaccent=False)
# ...
结构解读
parent_id: 一个Many2one字段，指向同一个模型account.account。它定义了“我属于谁”。child_ids: 一个One2many字段，是parent_id的反向关系。它定义了“谁属于我”。- 通过这两个字段，
account.account的记录被组织成了一棵树。一个没有parent_id的科目就是树的根节点。
一致性操作的威力
组合模式最大的威力在于，你可以对树上的任何一个节点（无论是叶子还是组合节点）执行相同的操作。
场景：计算一个科目的总余额
假设我们需要一个方法来计算某个会计科目及其所有子孙科目的总余额。
class AccountAccount(models.Model):
_inherit = 'account.account'
balance = fields.Monetary(compute='_compute_balance', string='Balance')
def _compute_balance(self):
for account in self:
# 对于当前科目，我们首先计算它自己的余额 (不含子科目)
# 简化逻辑，实际更复杂
# res = self.env['account.move.line'].read_group(...)
current_balance = account._get_own_balance()
# 关键：递归地处理子节点
# 我们对所有子节点求和，而子节点内部的计算也是通过同样的方式
children_balance = sum(child.balance for child in account.child_ids)
account.balance = current_balance + children_balance
代码分析
- 统一接口:
_compute_balance方法对所有account.account实例都可用。 - 透明性: 当你调用
some_account.balance时，你无需关心some_account是一个没有子科目的“叶子”科目，还是一个包含庞大家族的“组合”科目。- 如果它是叶子节点，
account.child_ids为空，children_balance为 0，结果就是它自身的余额。 - 如果它是组合节点，它会计算自身的余额，并递归地加上所有子孙的余额总和。
- 如果它是叶子节点，
sum(child.balance ...)这一行代码完美地体现了组合模式的精髓：对组合对象的操作，被委托给了其所有子组件。
另一个案例：物料清单 (BoM)
mrp.bom（物料清单）和 mrp.bom.line（清单行）是另一个经典的“部分-整体”结构，也应用了组合模式的思想。一个 BoM 可以包含原材料（叶子），也可以包含其他半成品的 BoM（组合）。计算一个最终产品的总成本时，就需要递归地展开所有层级的 BoM，累加所有组件的成本。
三、Odoo中的视图层支持
Odoo 的前端视图也对组合模式提供了强大的原生支持，最典型的就是**树状视图（Tree View）**的层级显示。
当你为一个实现了父子关系的模型（如 account.account）创建一个树状视图时，Odoo 会自动识别出 child_ids 字段，并以可展开/折叠的层级结构来展示数据。
<record id="view_account_list" model="ir.ui.view">
<field name="name">account.account.list</field>
<field name="model">account.account</field>
<field name="arch" type="xml">
<!-- Odoo自动识别父子关系，无需特殊配置 -->
<tree>
<field name="display_name"/>
<field name="code"/>
<field name="balance" sum="Total Balance"/>
</tree>
</field>
</record>
用户可以在 UI 上直观地与这个树形结构交互，而这背后正是组合模式在数据层面的支撑。
四、优势与注意事项
优势
- 简化客户端代码: 客户端可以统一处理所有对象，无需用
if/else来区分叶子和组合节点。 - 易于添加新组件: 可以很容易地向组合中添加新的叶子或组合节点，而无需改动现有代码，符合开闭原则。
- 天然匹配层级结构: 对于任何具有层级关系的需求，组合模式都是首选的、最自然的建模方式。
注意事项
- 性能考量: 深度递归操作可能会带来性能问题。对于层级很深的树，一次性计算所有子孙节点的属性可能会很慢。Odoo 为此提供了
parent_path和_parent_store = True这样的优化机制，它将每个节点的完整父路径存储在一个字段中，使得可以通过高效的 SQLLIKE查询来一次性获取所有子孙节点，避免了多次递归查询。 - “过于透明”的风险: 让叶子节点也拥有添加/删除子节点的方法（即使是空实现）可能会让接口不够安全。Odoo 通过
One2many和Many2one的机制很好地处理了这一点，你不能为一个记录的child_ids添加一个已经有parent_id的记录，ORM 层会自动处理这种约束。
结论
组合模式是 Odoo 中用于表示和操作层级数据结构的核心设计模式。它通过模型中简单的自引用关系，结合递归的方法调用，实现了对复杂树形结构的优雅、统一处理。
从会计科目、产品分类、组织架构到物料清单，组合模式无处不在。理解它，意味着你掌握了在 Odoo 中构建任何“部分-整体”层级系统的钥匙。当你面对一个具有树形结构的需求时，请自信地使用 parent_id 和 child_ids，并用递归的思路来设计你的业务方法，组合模式将是你最坚实的后盾。
基于odoo17的设计模式详解---组合模式