如何通过组合模式统一处理树形结构对象的层级一致性操作？

本文共计734个文字，预计阅读时间需要3分钟。

核心在于定义一个统一接口或抽象类，使叶子节点和容器节点都实现它，客户端端只面向这个接口编程，不关心具体类型。

明确三个关键角色

组合模式围绕 Component（抽象构件）、Leaf（叶子构件）、Composite（容器构件）展开：

• Component：声明通用操作，比如 display()、add()、remove()。它不强制所有子类都实现增删——这取决于你选透明方式还是安全方式
• Leaf：代表终端节点，如文件、菜单项、员工。它只实现自身行为（如 display()），对 add()/remove() 可抛异常或空实现
• Composite：代表分支节点，如文件夹、菜单组、部门。它持有一个 Component 列表，负责递归调用子节点的相同方法

选择透明方式还是安全方式

两种实现路径影响接口设计和调用逻辑：

• 透明方式：Component 中定义全部方法（包括 add/remove），Leaf 也必须实现它们（哪怕只是抛 UnsupportedOperationException）。优点是客户端完全无感，调用一致；缺点是语义上不合理的方法出现在 Leaf 中
• 安全方式：Component 只定义共用方法（如 display()），add/remove 等管理方法仅由 Composite 提供。优点是职责清晰；缺点是客户端使用前需 instanceof 判断类型，破坏了“一致性”的初衷

用文件系统举例说明操作一致性

假设要统一打印所有节点名称及缩进层级：

• File（Leaf）直接输出自己的 name 和 depth
• Directory（Composite）先输出自己，再遍历 children，对每个 child 调用 display(depth + 1)
• 客户端只需写 root.display(0)，无需判断 root 是文件还是文件夹，也不用写 if-else 或递归展开逻辑

注意边界与常见陷阱

实际落地时容易忽略几个细节：

• Composite 的 add/remove 方法应做 null 检查，避免空指针；同时建议限制重复添加（例如用 Set 替代 List 存储子节点）
• Leaf 的不可变性很重要——一旦设计为不可添加子节点，就不要在运行时允许动态转换角色
• 如果树很深，递归 display 或 search 可能引发栈溢出，可改用显式栈或队列实现迭代遍历
• Composite 中的 children 集合建议设为 protected 或提供只读视图（如 Collections.unmodifiableList），防止外部篡改结构