组合模式适合哪些应用场景？

简化版

组合模式适合具有树形层级结构，并且希望统一处理单个节点和组合节点的场景。典型应用包括文件目录、菜单树、组织架构、权限树、商品分类、UI 组件树、表达式树、评论嵌套和规则树。

详细版

常见应用：

1. 文件系统：文件和目录；
2. 菜单系统：菜单项和菜单组；
3. 组织架构：员工和部门；
4. 权限树：按钮权限和资源分组；
5. 商品分类：叶子分类和父分类；
6. UI 组件树：按钮、容器、面板；
7. 表达式树：数字节点和运算节点；
8. 评论系统：评论和子评论；
9. 规则引擎：单个规则和规则组；
10. 工作流节点树。

判断标准是：是否存在部分-整体关系，是否需要递归处理，是否希望客户端统一调用。

完整版教学

一、文件目录

文件目录是最经典场景。

文件是叶子，目录是组合。

统一操作包括：

• 计算大小；
• 打印目录结构；
• 搜索文件；
• 删除节点；
• 移动节点。

二、菜单和权限树

后台系统菜单常是多级结构。

权限树也类似：

系统管理
  用户管理
    新增用户
    删除用户

组合模式可以统一处理渲染、过滤、勾选状态和权限继承。

三、组织架构

组织架构里：

• 员工是叶子；
• 部门是组合；
• 公司是根组合。

统一操作包括统计人数、查找成员、打印组织树、计算部门成本。

四、UI 组件树

前端或 GUI 框架里，页面通常由组件树组成。

容器组件可以包含子组件，按钮、文本、图片等是叶子组件。

渲染时可以从根组件递归渲染整棵树。

五、表达式树和规则树

表达式：

(1 + 2) * 3

可以表示为树：

乘法节点
  加法节点
    数字 1
    数字 2
  数字 3

运算节点是组合，数字节点是叶子。

规则引擎中的 AND/OR 规则组也很适合这种结构。

六、不适合的场景

如果业务没有树形结构，或者层级固定且简单，就不一定需要组合模式。

例如普通订单对象包含订单明细，虽然也有包含关系，但如果只是一层结构，直接建模即可。

不要为了模式而模式。

七、常见误区与追问

组合模式适合稳定的部分—整体递归结构。菜单树有3层时，显示、授权过滤等操作可从根递归传播；表达式树则把求值统一到每个节点。若结构只是线性流水线，或父子节点没有共同业务操作，责任链、普通集合等方案更合适。

检查维度	判定依据
高匹配	树形结构且需要统一递归操作
低匹配	线性传递或节点行为没有共性

心法：同时满足“像树”和“要统一处理”两个条件，才考虑组合模式。

• 误区：组织架构有层级就必须套组合模式。 只有业务代码需要以统一接口递归处理部门和员工时才有价值。
• 追问：UI 组件树为何适合？ 容器和控件都能执行渲染、布局等统一操作，容器再传播给子组件。
• 误区：规则树与责任链完全相同。 规则树可分叉并组合结果，责任链通常沿线性后继传递请求。
• 追问：权限树需要注意什么？ 节点可见性可能依赖用户上下文，缓存结果不能跨用户误用。
• 追问：如何判断场景不适合？ 若客户端总要区分每种节点且没有公共操作，统一抽象只会制造复杂度。

八、加强记忆

组合模式适合树：文件目录、菜单权限、组织架构、商品分类、UI 组件、表达式树、规则树都很典型。判断时看三点：部分-整体、层级递归、一致处理。