设计模式里有一类很特别的结构型模式它看起来不起眼但一旦遇到树形层级数据它几乎就是最优雅的解法——这就是组合模式。组合模式的核心思想用一句话讲把对象组织成树形结构表示部分-整体的层次结构并让客户端对单个对象和组合对象的使用保持一致。我第一次意识到它的价值是在接手一个多级分类菜单系统时菜单有子菜单子菜单下面还有按钮处理起来到处是instanceof判断和递归代码又散又乱。用组合模式重构之后整个客户端调用变得非常干净新增一种节点类型也不用改调用方代码。组合模式适用的场景非常典型文件目录树、组织架构、多级菜单、商品分类、权限树、报表汇总、表单控件嵌套……凡是数据天然呈层级结构并且你需要统一地遍历、统计、展示这些层次数据时组合模式就是最直接的选择。这篇文章我会从组合模式的核心设计思路讲起结合一个真实的多级分类目录Demo把接口如何设计、递归如何写、边界问题如何处理全部拆开揉碎讲清楚。适合正在学设计模式、想在实际项目中落地的开发者也适合那些看过模式定义但不知道怎么用的人。1. 组合模式的设计初衷与核心思路1.1 没有组合模式时层级数据有多难处理先说痛点。假设你要做一个电商后台的商品分类系统分类可以无限级嵌套一级分类手机数码二级分类手机三级分类智能手机商品某品牌手机A商品某品牌手机B三级分类功能机二级分类笔记本一级分类家用电器二级分类冰箱二级分类电视如果你用传统反范式表硬写每层数据长不一样处理起来就是噩梦遍历一级分类要调getChildren()二级分类又要判断有没有child商品节点没有child就单独处理。客户端代码里塞满了if (node instanceof Category) 这种类型判断新增一个子分类类型时所有判断都要跟着改。更麻烦的是递归操作散落在各处。统计全部分类下商品总库存要写一个递归函数渲染菜单树又要写一个递归函数导出Excel还要写一个递归函数。你被迫复制粘贴同一套树形遍历逻辑改一个Bug要改三个地方。这就是典型的部分与整体被割裂处理的症状。组合模式要解决的核心问题就是让单个对象和组合对象暴露同样的接口。客户端不用关心自己正在处理的是叶子节点还是容器节点统一调用某个方法就行递归操作由容器节点自己内部去完成。这样处理层级数据的复杂度被封装到了组件内部而不是散落在客户端。1.2 核心思路组件接口 叶子节点 容器节点组合模式的结构非常清晰由三个角色组成Component抽象构件定义叶子节点和容器节点共有的接口比如getName()、getPrice()、display()以及管理子节点的方法add()、remove()、getChild()。Leaf叶子节点没有子节点的最终对象实现Component接口。它没有add、remove的实际意义但为了保持一致性通常空实现或抛异常。Composite容器节点有子节点的对象持有子节点集合实现 Component 接口并在方法内部递归调用子节点的方法。三个角色之间的关系说白了就是一棵树Composite 可以包含 Leaf也可以包含另一个 CompositeLeaf 在最底层。客户端面对的是统一的 Component 接口它调用的是叶子节点还是容器节点由运行时对象决定客户端根本不关心。用一个生活化的类比你在整理一个文件柜。文件柜里有文件夹文件夹里还可以套文件夹最底层是文件。如果你对文件柜说统计总页数文件柜不需要自己去翻每一页纸它只需要问每个子文件夹统计总页数子文件夹再问自己的子项……最后所有结果汇总到文件柜。整个过程里问你的是文件柜你不需要知道它是文件夹还是文件只要回答我有多少页就行。这就是部分-整体一致性。1.3 透明模式和安全模式选哪个组合模式在接口设计上有一个经典的分叉管理子节点的方法add/remove/getChild到底放在哪里透明模式把add/remove/getChild都声明在抽象构件 Component 里。这样叶子节点也必须实现这些方法通常空实现或抛UnsupportedOperationException。好处是客户端完全透明——所有节点都长得一模一样不用任何类型判断坏处是叶子节点被迫实现了无意义的方法不够安全。万一客户端在叶子节点上调用了add()结果可能是静默失败或抛异常体验有点别扭。安全模式Component 里只声明业务方法如getPrice()、getName()add/remove/getChild只放在 Composite 中。这样叶子节点不需要实现多余的方法安全得多。代价是客户端在遍历时如果拿着 Component 类型的引用就需要用 instanceof 判断是不是 Composite才能调用add/remove一致性打了折扣。我的建议很简单对比项透明模式安全模式管理方法位置Component接口Composite类叶子节点实现负担需要空实现/抛异常无需实现客户端一致性完全一致无需类型判断需要判断Composite类型安全性不安全误用add可能静默失败安全编译期就隔离典型场景菜单、控件树等强层级一致场景文件系统、业务树等叶子类型差异大的场景实际编码中我更喜欢折中方案接口里只声明业务方法管理方法放在 Composite 里但提供一个默认实现为抛异常的版本。这样客户端大部分时候不需要判断类型调用业务方法时而 add/remove 天然只在容器上有意义出错了有明确异常提示比静默失败好排查得多。2. 组合模式的角色拆解与关键细节2.1 三个角色的职责边界Component抽象构件是整棵树的共同语言。我见过不少设计把业务属性和方法一股脑全塞进去导致每个节点都有一堆不相关的字段。理想情况下Component 只应该暴露客户端真正在意的一致性能力比如展示自己、统计金额、导出数据。至于这个节点内部是叶子还是容器、有多少孩子、怎么管理孩子都是实现细节不该暴露在接口层。Leaf叶子节点是最简单的角色。它没有子节点不需要持有集合也不需要管理孩子。但注意这并不意味着 Leaf 的业务方法就一定是单行返回。比如一个商品叶子节点它的 getPrice() 可能要去查库存表、算折扣复杂着呢。只是从结构上讲它是树的最小单位不会再往下递归。Composite容器节点是整个模式的发动机。它持有一个子节点集合通常是 List 所有操作都会遍历子节点并递归调用。这里有个容易忽视的点Composite 本身可能也是一棵子树的根。一个分类下可以挂子分类子分类下再挂子分类这就是嵌套递归的来源。接口设计上还有几个隐藏的细节需要关注。第一个是命名粒度。getChild(int index) 是组合模式里常用的方法但实际业务中你可能更常用 findById(String id) 来定位节点。接口方法应该贴合业务语义而不是死抠模式定义。如果你硬要一个 getChild(int index)但在真实场景里没人用这个接口就是死的。第二个是集合暴露方式。有些实现直接在 getChildren() 里返回内部 List 对象这非常危险——调用方拿到这个 List 后可以随意 add/remove绕过你所有的封装逻辑。要么返回 Collections.unmodifiableList()要么干脆只提供 size() getChild(i) 的只读访问。第三个是缓存问题。如果一棵树有上万个节点每次调用 getPrice() 都全量遍历一遍性能很差。一个很值得做的优化是Composite 内部维护一个 cachedPrice当子节点变化时add/remove 时标记缓存失效调用 getPrice() 时如果缓存有效就直接返回。这在报表统计、价格汇总场景下提升非常明显。2.2 接口设计的关键决策add/remove 放哪里这是所有初学者最容易纠结的地方。坦白说没有绝对正确的答案但有几个判断依据可以帮你决策你的叶子节点会不会被客户端错误地调用 add()如果经过你的接口设计客户端根本不可能拿到任意 Component 引用去调用 add那么透明模式是安全的。但如果客户端随手就能拿到一个 Leaf那安全模式更稳妥。你的树是稳定结构还是动态结构如果运行时经常增删节点比如动态菜单编辑管理操作会被频繁调用建议把 add/remove 暴露在 Composite 上并用类型判断隔离如果树结构构建后基本不变那透明模式的便利性更重要。你是不是会做很多从根开始的无差别遍历这种场景下透明模式的无类型判断遍历非常爽遍历到每个节点时直接调用 display()根本不用管它是叶子还是容器。从我带过的一个模拟项目 X一个多级权限菜单系统的经验看菜单树的最佳实践是public interface MenuNode { String getName(); void display(); // 默认实现抛异常表示叶子节点不支持 default void add(MenuNode child) { throw new UnsupportedOperationException(当前节点不支持添加子节点); } }然后 Composite 里重写 addLeaf 里不用管。这样既保持了透明模式的遍历一致性又通过默认异常避免了静默失败。你可以在 Composite 里加一个 boolean isLeaf() 方法方便客户端在需要时判断但日常遍历根本用不到。2.3 递归调用的底层逻辑组合模式与递归是天然绑定的。容器节点的每个业务方法几乎都是在遍历子节点并递归调用相同的业务方法。递归之所以在这里合适是因为树形结构本身就是递归定义的一棵树要么是叶子要么是容器加若干子树。用递归来表达树的操作与数据结构本身完全同构。但递归不是写个函数自己调自己这么简单。一个写好的递归方法需要满足三个条件终止条件递归到叶子节点时必须能停下。在组合模式中叶子节点直接返回结果就是终止条件。递推关系当前节点的结果等于子节点结果的处理。比如统计总价sum 自身价格 sum(所有子节点价格)。递归方向必须向着更小/更深的方向前进绝不允许出现环。递归的经典写法分先序和后序。以统计总价为例后序先子后父先递归计算所有子节点的总价再加上自己的价格。适合汇总类操作。先序先父后子先处理自己的价格再处理子节点。适合展示类操作比如打印目录树时先打印自己的名字再递归打印子节点。这两者的区别很多人一开始体会不出来。我举个直观例子展示一棵树的缩进结构你不先打印父节点子节点就没法算缩进层级所以要用先序计算整颗树的总价你不先把子节点算完父节点就不知道自己的总和所以要用后序。搞清楚这个逻辑写递归就不会凭感觉了。3. 实操用组合模式实现一个多级商品分类目录3.1 场景设定与需求分析为了把前面的理论落到地上我们做一个多级商品分类目录系统。需求如下分类可以多级嵌套比如手机数码 手机 智能手机 某品牌旗舰机每个节点有名称和价格。分类节点的价格由子节点累加得出商品节点价格是自身价格提供一个display()方法按树形缩进展示整棵目录提供一个getTotalPrice()方法统计任意节点下所有商品的总价将来可能新增优惠券节点套餐节点等类型不能影响现有调用代码这个需求里封装变化的关键点在于三种节点最终都会在display()和getTotalPrice()上保持一致行为。用组合模式新增节点类型时只需要新写一个 Component 实现类即可客户端代码一行不用改。3.2 代码实现组件接口 叶子节点 容器节点我用 Java 来写因为 Java 对设计模式的表达最清晰你换成 TypeScript、Python、C# 思路完全一样。先定义组件接口import java.util.List; public interface ProductComponent { String getName(); double getTotalPrice(); void display(String indent); default void add(ProductComponent child) { throw new UnsupportedOperationException(当前节点不支持添加子节点); } default void remove(ProductComponent child) { throw new UnsupportedOperationException(当前节点不支持移除子节点); } }注意这里我用了 default 方法叶子节点就直接默认抛异常不需要白写空实现。然后是叶子节点——商品public class Product implements ProductComponent { private final String name; private final double price; public Product(String name, double price) { this.name name; this.price price; } Override public String getName() { return name; } Override public double getTotalPrice() { return price; } Override public void display(String indent) { System.out.println(indent 商品: name (¥ price )); } }再看容器节点——分类import java.util.ArrayList; import java.util.List; public class Category implements ProductComponent { private final String name; private final ListProductComponent children new ArrayList(); public Category(String name) { this.name name; } Override public String getName() { return name; } Override public void add(ProductComponent child) { children.add(child); } Override public void remove(ProductComponent child) { children.remove(child); } Override public double getTotalPrice() { double total 0; for (ProductComponent child : children) { total child.getTotalPrice(); // 递归调用 } return total; } Override public void display(String indent) { System.out.println(indent 分类: name); for (ProductComponent child : children) { child.display(indent ); // 缩进遍历 } } }你发现没有Category 里 getTotalPrice() 和 display() 都没有判断子节点类型直接对每个 child 调用同样的方法。这就是组合模式的核心妙处递归调用代替了类型判断。3.3 递归统计总价与遍历节点搭一个树形结构测试一下public class Demo { public static void main(String[] args) { // 构建树: 手机数码 手机 智能手机 品牌手机 ProductComponent root new Category(手机数码); ProductComponent phoneCategory new Category(手机); phoneCategory.add(new Product(某品牌手机A, 5999)); phoneCategory.add(new Product(某品牌手机B, 4999)); ProductComponent smartPhone new Category(智能手机); smartPhone.add(new Product(旗舰机型X, 8999)); smartPhone.add(new Product(旗舰机型Y, 7999)); phoneCategory.add(smartPhone); root.add(phoneCategory); ProductComponent laptopCategory new Category(笔记本); laptopCategory.add(new Product(轻薄本Z, 6799)); root.add(laptopCategory); root.display(); double total root.getTotalPrice(); System.out.println(全部商品总价: ¥ total); // 单独统计手机子分类总价 double phoneTotal phoneCategory.getTotalPrice(); System.out.println(手机分类总价: ¥ phoneTotal); } }输出的结果是分类: 手机数码 分类: 手机 商品: 某品牌手机A (¥5999.0) 商品: 某品牌手机B (¥4999.0) 分类: 智能手机 商品: 旗舰机型X (¥8999.0) 商品: 旗舰机型Y (¥7999.0) 分类: 笔记本 商品: 轻薄本Z (¥6799.0) 全部商品总价: ¥34795.0 手机分类总价: ¥27996.0注意写法上的几个细节。第一display(String indent) 的参数是缩进字符串而不是缩进层级整数。这样设计调用起来非常方便每个节点调用时只需要在后面加两个空格即可。你用 int depth 也行但每次都要算空格拼接不直观。这算是我个人经验里比较推荐的小技巧。第二getTotalPrice() 是后序递归。先算完全部孩子的价格再返回总和。你看代码流程确实没有显式地先子后父但天然就是后序——因为 total 累加发生在递归调用返回之后。第三Category 也是一个 ProductComponent所以它可以被 add 到其他 Category 里。这就是嵌套递归的扩展点。你想新增品牌分类只需要 Category brand new Category(品牌)然后 add 进去整棵树依然正常工作。再说一个实际编码时的常见坑集合的遍历过程中不要直接修改集合。如果在递归时 add/remove 子节点可能抛 ConcurrentModificationException 或产生漏遍历。组合模式建议的姿势是遍历display/getTotalPrice只读集合需要修改树结构时先定位节点再执行 add/remove不要在遍历期间改动。4. 递归执行操作时的坑与排查技巧4.1 栈溢出树太深怎么办组合模式和递归绑定递归最大的敌人之一是栈溢出。JVM 默认线程栈通常 512KB~1MB一次递归调用栈帧少说也要占几百字节。当地址深度达到几千层时就可能 StackOverflowError。实际业务中像商品分类这种树通常不会超过 10 层栈溢出不容易碰到。但有些场景要警惕配置文件树、报表维度树、表达式树这些树的深度在某些极端数据下可能达到几千层。如果一个树构造不当导致栈溢出排查思路分三步确认树的实际深度。写一个递归方法计算深度如果超过 1000就要考虑转迭代实现。确认递归中是否有大量局部变量。比如在递归方法里复制了数组栈帧容量陡增几百层就可能爆栈。用显式栈转迭代。树的前序/后序遍历都可以改成 Stack 或手动记录的遍历状态代价是代码更复杂可读性下降。我的建议是先做深度检测不要盲目优化。90% 的业务树深度都在 100 以内递归写法可读性极高真到了万不得已再针对性地转迭代。盲目将递归改成迭代会让代码失去组合模式的一致性表达优势。4.2 无限递归环形引用是元凶比栈溢出更隐蔽的 Bug 是无限递归。典型场景是一个 Category A 的 children 列表里add 了 Category B而 B 又 add 了 A。当你调用 A.getTotalPrice() 时A 问 BB 问 AA 问 B……死循环直到栈溢出。这种问题好排查但很难从代码逻辑上肉眼发现。我多次踩坑之后总结了一套防御方案add 方法里做环检测。新加入的 child 不能是当前节点自身也不能是当前节点的祖先。实现方式是向上遍历父链。如果 Composite 不持有父引用可以遍历全树判断 child 是否已存在于当前节点的子树路径中。加 visited 集合。递归遍历时用一个 HashSet 记录访问过的节点 id如果重复出现直接抛出业务异常提示检测到环形引用。这个方案在多线程环境下要小心并发问题。在业务层约束。比如分类树只允许通过管理后台接口构建接口逻辑保证不会出现环。这是最干净的方案但实现时容易遗漏。最典型的 Ring 出现场景是从 Excel 批量导入目录树时A 的父节点 id 错了指向了自己的子节点。这时构建树时就要校验父子关系。4.3 空指针与叶子节点的误操作还有一个非常常见的崩溃点在 Composite 的递归方法里child 引用是 null。比如反序列化 JSON 时某个节点的 children 字段缺失初始化成 null递归遍历时直接 NPE。这个坑的排查口诀很简单集合字段要么赋空集合要么在递归时判空。我自己的习惯是在 Composite 的构造方法里就初始化 children new ArrayList()不允许它为 null。这样递归遍历永远安全。如果你控制不了反序列化过程比如对外接口传进来的 JSON那就在 add 和遍历方法里对 child 做空判断或者用 Stream 的 filter 过滤掉 null。叶子节点误操作 add 的问题则完全属于接口设计范畴。如果你用了透明模式且默认方法是抛异常那么报错信息要写得够清晰别只抛个 UnsupportedOperationException 就完事。一定要带上节点名称和操作类型比如throw new UnsupportedOperationException( 叶子节点[ name ]不支持添加子节点请检查调用逻辑 );排查问题时报错信息本身就是最直接的线索。我一直强调生产环境里异常信息说人话比写一堆注释有用得多。4.4 性能瓶颈重复递归与全量遍历组合模式的递归操作天然是 O(n) 全量遍历如果一棵树几万个节点每次 getTotalPrice() 都全量遍历调用多了性能就很差。这里有一个很实用的优化策略容器节点缓存汇总值。Category 的内部可以加一个 Double computedTotalPrice 字段默认 null。add/remove 时将这个节点和所有父节点的缓存清空getTotalPrice() 时如果缓存不为 null 就直接返回缓存。这样只有树结构变化时才会重新计算总价查询类操作几乎零成本。类似的思路也适用于节点数量统计最深深度这类聚合操作。不过要注意缓存失效的正确性你新增了一个子节点影响的不仅是当前节点还有当前节点的所有祖先节点。如果 Category 不持有父引用缓存失效要借助向上传递机制。最省事的做法是在 add 方法里手动调用一个 invalidateCache()然后层层向上通知父节点。持有一个 Parent 引用最简单。如果嫌弃持有父引用会破坏树结构纯度也有折中方案构建阶段完成后不加节点把树视为不可变结构直接一次性算好所有汇总值存到字段里。用不可变树 构建时全量计算的方案查询时直接 O(1)比实时遍历快太多了。5. 组合模式的实际应用场景与扩展思路5.1 不只是文件目录菜单、权限、报表、表达式组合模式最容易想到的应用是文件目录、菜单树但它的价值远不止这些。权限管理权限树是部分-整体的典型代表。一个角色下挂多个权限点权限点又有父子关系。判断是否有某个权限时不需要关心当前权限点是叶子还是分组统一调用 checkPermission() 就行。报表系统报表的行和列可以嵌套。一个汇总单元格由多个明细单元格组成明细单元格还可以再嵌套。用组合模式设计单元格结构求合计值就是递归相加。表达式引擎表达式本身就是递归定义的。一个加减表达式由数字、运算符、子表达式组成。我们可以设计一个 ExpressionNode 接口NumberNode 实现叶子求值OperationNode 实现递归求值。这是解释器模式常见的实现基础而组合模式提供了结构骨架。表单设计器表单里有输入框、下拉框、还有容器比如字段集、分组框容器里又能放任意控件。渲染表单统一调用 render()校验输入统一调用 validate()每次都不需要判断控件类型新加一个空间类型也无缝接入。这些场景有一个共性客户端需要无差别地处理单个对象和对象集合。找到这个共性你就能判断是否该上组合模式。5.2 组合模式和访问者模式搭配使用组合模式有一个天然的软肋如果你想在树上增加一个新操作比如导出Excel、生成JSON只能给每个节点类加方法。改的节点越多代码侵入越强。这时候可以把访问者模式请出来。组合模式提供树的稳定结构访问者模式把操作从节点类里抽离出来。你定义一个 Visitor 接口里面有 visit(Category) 和 visit(Product)每个节点实现accept(Visitor v)递归遍历时自动调用对应的 visit 方法。以后要加新操作写一个新 Visitor 就行节点类完全不用改。这种组合为骨、访问者为魂的搭配在报表引擎、规则引擎里非常常见。如果你发现要在组合模式树上频繁增加横向操作我强烈建议引入访问者。5.3 什么时候不该用组合模式组合模式虽好但它不是一个万能模式用错了反而让代码更难维护。层级非常浅且固定比如只有两层分类-商品不存在分类套分类。这种场景用两个独立的类就够了强行上组合模式只会增加抽象复杂度。叶子节点类型差异过大如果叶子节点之间的行为差异极大接口只能被迫声明一堆方法叶子节点的实现里全是空方法或抛异常组合模式就成了接口污染。树结构频繁变化且并发高组合模式对树结构的修改操作通常不是线程安全的如果高并发场景下需要频繁 add/remove你要额外加锁或引入不可变树方案复杂度会大幅上升。选择模式最重要的是性价比。如果简单嵌套结构用 if-else 就可以那就别为了用设计模式而用设计模式。组合模式的优势一定是在深度嵌套 需要统一操作 结构可能扩展三者的交集里才会完全释放。说了这么多最后分享一点个人经验。我上手组合模式时走了一些弯路最大的体会是不要急着把所有的树都变成组合模式要先把统一操作找出来。如果一棵树只有遍历一个操作组合模式的收益不够明显一旦你发现在三个不同的地方都对这棵树做递归聚合操作组合模式就会带来质的提升重复代码会快速收缩。另一个建议是从最简单的叶子节点开始写先让单个商品节点的行为正确再写容器节点。容器节点的递归逻辑一旦写好叶子节点再多也不怕。调试时打印缩进树结构是检查递归正确性的最直观方法我在实盘项目里一直靠这个快速定位递归边界问题。组合模式看着简单真正用好还是需要不少手感。希望这篇文章能帮你把这个模式用得明明白白少踩几个我当年踩过的坑。
设计模式里有一类很特别的结构型模式它看起来不起眼但一旦遇到树形层级数据它几乎就是最优雅的解法——这就是组合模式。组合模式的核心思想用一句话讲把对象组织成树形结构表示部分-整体的层次结构并让客户端对单个对象和组合对象的使用保持一致。我第一次意识到它的价值是在接手一个多级分类菜单系统时菜单有子菜单子菜单下面还有按钮处理起来到处是instanceof判断和递归代码又散又乱。用组合模式重构之后整个客户端调用变得非常干净新增一种节点类型也不用改调用方代码。组合模式适用的场景非常典型文件目录树、组织架构、多级菜单、商品分类、权限树、报表汇总、表单控件嵌套……凡是数据天然呈层级结构并且你需要统一地遍历、统计、展示这些层次数据时组合模式就是最直接的选择。这篇文章我会从组合模式的核心设计思路讲起结合一个真实的多级分类目录Demo把接口如何设计、递归如何写、边界问题如何处理全部拆开揉碎讲清楚。适合正在学设计模式、想在实际项目中落地的开发者也适合那些看过模式定义但不知道怎么用的人。1. 组合模式的设计初衷与核心思路1.1 没有组合模式时层级数据有多难处理先说痛点。假设你要做一个电商后台的商品分类系统分类可以无限级嵌套一级分类手机数码二级分类手机三级分类智能手机商品某品牌手机A商品某品牌手机B三级分类功能机二级分类笔记本一级分类家用电器二级分类冰箱二级分类电视如果你用传统反范式表硬写每层数据长不一样处理起来就是噩梦遍历一级分类要调getChildren()二级分类又要判断有没有child商品节点没有child就单独处理。客户端代码里塞满了if (node instanceof Category) 这种类型判断新增一个子分类类型时所有判断都要跟着改。更麻烦的是递归操作散落在各处。统计全部分类下商品总库存要写一个递归函数渲染菜单树又要写一个递归函数导出Excel还要写一个递归函数。你被迫复制粘贴同一套树形遍历逻辑改一个Bug要改三个地方。这就是典型的部分与整体被割裂处理的症状。组合模式要解决的核心问题就是让单个对象和组合对象暴露同样的接口。客户端不用关心自己正在处理的是叶子节点还是容器节点统一调用某个方法就行递归操作由容器节点自己内部去完成。这样处理层级数据的复杂度被封装到了组件内部而不是散落在客户端。1.2 核心思路组件接口 叶子节点 容器节点组合模式的结构非常清晰由三个角色组成Component抽象构件定义叶子节点和容器节点共有的接口比如getName()、getPrice()、display()以及管理子节点的方法add()、remove()、getChild()。Leaf叶子节点没有子节点的最终对象实现Component接口。它没有add、remove的实际意义但为了保持一致性通常空实现或抛异常。Composite容器节点有子节点的对象持有子节点集合实现 Component 接口并在方法内部递归调用子节点的方法。三个角色之间的关系说白了就是一棵树Composite 可以包含 Leaf也可以包含另一个 CompositeLeaf 在最底层。客户端面对的是统一的 Component 接口它调用的是叶子节点还是容器节点由运行时对象决定客户端根本不关心。用一个生活化的类比你在整理一个文件柜。文件柜里有文件夹文件夹里还可以套文件夹最底层是文件。如果你对文件柜说统计总页数文件柜不需要自己去翻每一页纸它只需要问每个子文件夹统计总页数子文件夹再问自己的子项……最后所有结果汇总到文件柜。整个过程里问你的是文件柜你不需要知道它是文件夹还是文件只要回答我有多少页就行。这就是部分-整体一致性。1.3 透明模式和安全模式选哪个组合模式在接口设计上有一个经典的分叉管理子节点的方法add/remove/getChild到底放在哪里透明模式把add/remove/getChild都声明在抽象构件 Component 里。这样叶子节点也必须实现这些方法通常空实现或抛UnsupportedOperationException。好处是客户端完全透明——所有节点都长得一模一样不用任何类型判断坏处是叶子节点被迫实现了无意义的方法不够安全。万一客户端在叶子节点上调用了add()结果可能是静默失败或抛异常体验有点别扭。安全模式Component 里只声明业务方法如getPrice()、getName()add/remove/getChild只放在 Composite 中。这样叶子节点不需要实现多余的方法安全得多。代价是客户端在遍历时如果拿着 Component 类型的引用就需要用 instanceof 判断是不是 Composite才能调用add/remove一致性打了折扣。我的建议很简单对比项透明模式安全模式管理方法位置Component接口Composite类叶子节点实现负担需要空实现/抛异常无需实现客户端一致性完全一致无需类型判断需要判断Composite类型安全性不安全误用add可能静默失败安全编译期就隔离典型场景菜单、控件树等强层级一致场景文件系统、业务树等叶子类型差异大的场景实际编码中我更喜欢折中方案接口里只声明业务方法管理方法放在 Composite 里但提供一个默认实现为抛异常的版本。这样客户端大部分时候不需要判断类型调用业务方法时而 add/remove 天然只在容器上有意义出错了有明确异常提示比静默失败好排查得多。2. 组合模式的角色拆解与关键细节2.1 三个角色的职责边界Component抽象构件是整棵树的共同语言。我见过不少设计把业务属性和方法一股脑全塞进去导致每个节点都有一堆不相关的字段。理想情况下Component 只应该暴露客户端真正在意的一致性能力比如展示自己、统计金额、导出数据。至于这个节点内部是叶子还是容器、有多少孩子、怎么管理孩子都是实现细节不该暴露在接口层。Leaf叶子节点是最简单的角色。它没有子节点不需要持有集合也不需要管理孩子。但注意这并不意味着 Leaf 的业务方法就一定是单行返回。比如一个商品叶子节点它的 getPrice() 可能要去查库存表、算折扣复杂着呢。只是从结构上讲它是树的最小单位不会再往下递归。Composite容器节点是整个模式的发动机。它持有一个子节点集合通常是 List 所有操作都会遍历子节点并递归调用。这里有个容易忽视的点Composite 本身可能也是一棵子树的根。一个分类下可以挂子分类子分类下再挂子分类这就是嵌套递归的来源。接口设计上还有几个隐藏的细节需要关注。第一个是命名粒度。getChild(int index) 是组合模式里常用的方法但实际业务中你可能更常用 findById(String id) 来定位节点。接口方法应该贴合业务语义而不是死抠模式定义。如果你硬要一个 getChild(int index)但在真实场景里没人用这个接口就是死的。第二个是集合暴露方式。有些实现直接在 getChildren() 里返回内部 List 对象这非常危险——调用方拿到这个 List 后可以随意 add/remove绕过你所有的封装逻辑。要么返回 Collections.unmodifiableList()要么干脆只提供 size() getChild(i) 的只读访问。第三个是缓存问题。如果一棵树有上万个节点每次调用 getPrice() 都全量遍历一遍性能很差。一个很值得做的优化是Composite 内部维护一个 cachedPrice当子节点变化时add/remove 时标记缓存失效调用 getPrice() 时如果缓存有效就直接返回。这在报表统计、价格汇总场景下提升非常明显。2.2 接口设计的关键决策add/remove 放哪里这是所有初学者最容易纠结的地方。坦白说没有绝对正确的答案但有几个判断依据可以帮你决策你的叶子节点会不会被客户端错误地调用 add()如果经过你的接口设计客户端根本不可能拿到任意 Component 引用去调用 add那么透明模式是安全的。但如果客户端随手就能拿到一个 Leaf那安全模式更稳妥。你的树是稳定结构还是动态结构如果运行时经常增删节点比如动态菜单编辑管理操作会被频繁调用建议把 add/remove 暴露在 Composite 上并用类型判断隔离如果树结构构建后基本不变那透明模式的便利性更重要。你是不是会做很多从根开始的无差别遍历这种场景下透明模式的无类型判断遍历非常爽遍历到每个节点时直接调用 display()根本不用管它是叶子还是容器。从我带过的一个模拟项目 X一个多级权限菜单系统的经验看菜单树的最佳实践是public interface MenuNode { String getName(); void display(); // 默认实现抛异常表示叶子节点不支持 default void add(MenuNode child) { throw new UnsupportedOperationException(当前节点不支持添加子节点); } }然后 Composite 里重写 addLeaf 里不用管。这样既保持了透明模式的遍历一致性又通过默认异常避免了静默失败。你可以在 Composite 里加一个 boolean isLeaf() 方法方便客户端在需要时判断但日常遍历根本用不到。2.3 递归调用的底层逻辑组合模式与递归是天然绑定的。容器节点的每个业务方法几乎都是在遍历子节点并递归调用相同的业务方法。递归之所以在这里合适是因为树形结构本身就是递归定义的一棵树要么是叶子要么是容器加若干子树。用递归来表达树的操作与数据结构本身完全同构。但递归不是写个函数自己调自己这么简单。一个写好的递归方法需要满足三个条件终止条件递归到叶子节点时必须能停下。在组合模式中叶子节点直接返回结果就是终止条件。递推关系当前节点的结果等于子节点结果的处理。比如统计总价sum 自身价格 sum(所有子节点价格)。递归方向必须向着更小/更深的方向前进绝不允许出现环。递归的经典写法分先序和后序。以统计总价为例后序先子后父先递归计算所有子节点的总价再加上自己的价格。适合汇总类操作。先序先父后子先处理自己的价格再处理子节点。适合展示类操作比如打印目录树时先打印自己的名字再递归打印子节点。这两者的区别很多人一开始体会不出来。我举个直观例子展示一棵树的缩进结构你不先打印父节点子节点就没法算缩进层级所以要用先序计算整颗树的总价你不先把子节点算完父节点就不知道自己的总和所以要用后序。搞清楚这个逻辑写递归就不会凭感觉了。3. 实操用组合模式实现一个多级商品分类目录3.1 场景设定与需求分析为了把前面的理论落到地上我们做一个多级商品分类目录系统。需求如下分类可以多级嵌套比如手机数码 手机 智能手机 某品牌旗舰机每个节点有名称和价格。分类节点的价格由子节点累加得出商品节点价格是自身价格提供一个display()方法按树形缩进展示整棵目录提供一个getTotalPrice()方法统计任意节点下所有商品的总价将来可能新增优惠券节点套餐节点等类型不能影响现有调用代码这个需求里封装变化的关键点在于三种节点最终都会在display()和getTotalPrice()上保持一致行为。用组合模式新增节点类型时只需要新写一个 Component 实现类即可客户端代码一行不用改。3.2 代码实现组件接口 叶子节点 容器节点我用 Java 来写因为 Java 对设计模式的表达最清晰你换成 TypeScript、Python、C# 思路完全一样。先定义组件接口import java.util.List; public interface ProductComponent { String getName(); double getTotalPrice(); void display(String indent); default void add(ProductComponent child) { throw new UnsupportedOperationException(当前节点不支持添加子节点); } default void remove(ProductComponent child) { throw new UnsupportedOperationException(当前节点不支持移除子节点); } }注意这里我用了 default 方法叶子节点就直接默认抛异常不需要白写空实现。然后是叶子节点——商品public class Product implements ProductComponent { private final String name; private final double price; public Product(String name, double price) { this.name name; this.price price; } Override public String getName() { return name; } Override public double getTotalPrice() { return price; } Override public void display(String indent) { System.out.println(indent 商品: name (¥ price )); } }再看容器节点——分类import java.util.ArrayList; import java.util.List; public class Category implements ProductComponent { private final String name; private final ListProductComponent children new ArrayList(); public Category(String name) { this.name name; } Override public String getName() { return name; } Override public void add(ProductComponent child) { children.add(child); } Override public void remove(ProductComponent child) { children.remove(child); } Override public double getTotalPrice() { double total 0; for (ProductComponent child : children) { total child.getTotalPrice(); // 递归调用 } return total; } Override public void display(String indent) { System.out.println(indent 分类: name); for (ProductComponent child : children) { child.display(indent ); // 缩进遍历 } } }你发现没有Category 里 getTotalPrice() 和 display() 都没有判断子节点类型直接对每个 child 调用同样的方法。这就是组合模式的核心妙处递归调用代替了类型判断。3.3 递归统计总价与遍历节点搭一个树形结构测试一下public class Demo { public static void main(String[] args) { // 构建树: 手机数码 手机 智能手机 品牌手机 ProductComponent root new Category(手机数码); ProductComponent phoneCategory new Category(手机); phoneCategory.add(new Product(某品牌手机A, 5999)); phoneCategory.add(new Product(某品牌手机B, 4999)); ProductComponent smartPhone new Category(智能手机); smartPhone.add(new Product(旗舰机型X, 8999)); smartPhone.add(new Product(旗舰机型Y, 7999)); phoneCategory.add(smartPhone); root.add(phoneCategory); ProductComponent laptopCategory new Category(笔记本); laptopCategory.add(new Product(轻薄本Z, 6799)); root.add(laptopCategory); root.display(); double total root.getTotalPrice(); System.out.println(全部商品总价: ¥ total); // 单独统计手机子分类总价 double phoneTotal phoneCategory.getTotalPrice(); System.out.println(手机分类总价: ¥ phoneTotal); } }输出的结果是分类: 手机数码 分类: 手机 商品: 某品牌手机A (¥5999.0) 商品: 某品牌手机B (¥4999.0) 分类: 智能手机 商品: 旗舰机型X (¥8999.0) 商品: 旗舰机型Y (¥7999.0) 分类: 笔记本 商品: 轻薄本Z (¥6799.0) 全部商品总价: ¥34795.0 手机分类总价: ¥27996.0注意写法上的几个细节。第一display(String indent) 的参数是缩进字符串而不是缩进层级整数。这样设计调用起来非常方便每个节点调用时只需要在后面加两个空格即可。你用 int depth 也行但每次都要算空格拼接不直观。这算是我个人经验里比较推荐的小技巧。第二getTotalPrice() 是后序递归。先算完全部孩子的价格再返回总和。你看代码流程确实没有显式地先子后父但天然就是后序——因为 total 累加发生在递归调用返回之后。第三Category 也是一个 ProductComponent所以它可以被 add 到其他 Category 里。这就是嵌套递归的扩展点。你想新增品牌分类只需要 Category brand new Category(品牌)然后 add 进去整棵树依然正常工作。再说一个实际编码时的常见坑集合的遍历过程中不要直接修改集合。如果在递归时 add/remove 子节点可能抛 ConcurrentModificationException 或产生漏遍历。组合模式建议的姿势是遍历display/getTotalPrice只读集合需要修改树结构时先定位节点再执行 add/remove不要在遍历期间改动。4. 递归执行操作时的坑与排查技巧4.1 栈溢出树太深怎么办组合模式和递归绑定递归最大的敌人之一是栈溢出。JVM 默认线程栈通常 512KB~1MB一次递归调用栈帧少说也要占几百字节。当地址深度达到几千层时就可能 StackOverflowError。实际业务中像商品分类这种树通常不会超过 10 层栈溢出不容易碰到。但有些场景要警惕配置文件树、报表维度树、表达式树这些树的深度在某些极端数据下可能达到几千层。如果一个树构造不当导致栈溢出排查思路分三步确认树的实际深度。写一个递归方法计算深度如果超过 1000就要考虑转迭代实现。确认递归中是否有大量局部变量。比如在递归方法里复制了数组栈帧容量陡增几百层就可能爆栈。用显式栈转迭代。树的前序/后序遍历都可以改成 Stack 或手动记录的遍历状态代价是代码更复杂可读性下降。我的建议是先做深度检测不要盲目优化。90% 的业务树深度都在 100 以内递归写法可读性极高真到了万不得已再针对性地转迭代。盲目将递归改成迭代会让代码失去组合模式的一致性表达优势。4.2 无限递归环形引用是元凶比栈溢出更隐蔽的 Bug 是无限递归。典型场景是一个 Category A 的 children 列表里add 了 Category B而 B 又 add 了 A。当你调用 A.getTotalPrice() 时A 问 BB 问 AA 问 B……死循环直到栈溢出。这种问题好排查但很难从代码逻辑上肉眼发现。我多次踩坑之后总结了一套防御方案add 方法里做环检测。新加入的 child 不能是当前节点自身也不能是当前节点的祖先。实现方式是向上遍历父链。如果 Composite 不持有父引用可以遍历全树判断 child 是否已存在于当前节点的子树路径中。加 visited 集合。递归遍历时用一个 HashSet 记录访问过的节点 id如果重复出现直接抛出业务异常提示检测到环形引用。这个方案在多线程环境下要小心并发问题。在业务层约束。比如分类树只允许通过管理后台接口构建接口逻辑保证不会出现环。这是最干净的方案但实现时容易遗漏。最典型的 Ring 出现场景是从 Excel 批量导入目录树时A 的父节点 id 错了指向了自己的子节点。这时构建树时就要校验父子关系。4.3 空指针与叶子节点的误操作还有一个非常常见的崩溃点在 Composite 的递归方法里child 引用是 null。比如反序列化 JSON 时某个节点的 children 字段缺失初始化成 null递归遍历时直接 NPE。这个坑的排查口诀很简单集合字段要么赋空集合要么在递归时判空。我自己的习惯是在 Composite 的构造方法里就初始化 children new ArrayList()不允许它为 null。这样递归遍历永远安全。如果你控制不了反序列化过程比如对外接口传进来的 JSON那就在 add 和遍历方法里对 child 做空判断或者用 Stream 的 filter 过滤掉 null。叶子节点误操作 add 的问题则完全属于接口设计范畴。如果你用了透明模式且默认方法是抛异常那么报错信息要写得够清晰别只抛个 UnsupportedOperationException 就完事。一定要带上节点名称和操作类型比如throw new UnsupportedOperationException( 叶子节点[ name ]不支持添加子节点请检查调用逻辑 );排查问题时报错信息本身就是最直接的线索。我一直强调生产环境里异常信息说人话比写一堆注释有用得多。4.4 性能瓶颈重复递归与全量遍历组合模式的递归操作天然是 O(n) 全量遍历如果一棵树几万个节点每次 getTotalPrice() 都全量遍历调用多了性能就很差。这里有一个很实用的优化策略容器节点缓存汇总值。Category 的内部可以加一个 Double computedTotalPrice 字段默认 null。add/remove 时将这个节点和所有父节点的缓存清空getTotalPrice() 时如果缓存不为 null 就直接返回缓存。这样只有树结构变化时才会重新计算总价查询类操作几乎零成本。类似的思路也适用于节点数量统计最深深度这类聚合操作。不过要注意缓存失效的正确性你新增了一个子节点影响的不仅是当前节点还有当前节点的所有祖先节点。如果 Category 不持有父引用缓存失效要借助向上传递机制。最省事的做法是在 add 方法里手动调用一个 invalidateCache()然后层层向上通知父节点。持有一个 Parent 引用最简单。如果嫌弃持有父引用会破坏树结构纯度也有折中方案构建阶段完成后不加节点把树视为不可变结构直接一次性算好所有汇总值存到字段里。用不可变树 构建时全量计算的方案查询时直接 O(1)比实时遍历快太多了。5. 组合模式的实际应用场景与扩展思路5.1 不只是文件目录菜单、权限、报表、表达式组合模式最容易想到的应用是文件目录、菜单树但它的价值远不止这些。权限管理权限树是部分-整体的典型代表。一个角色下挂多个权限点权限点又有父子关系。判断是否有某个权限时不需要关心当前权限点是叶子还是分组统一调用 checkPermission() 就行。报表系统报表的行和列可以嵌套。一个汇总单元格由多个明细单元格组成明细单元格还可以再嵌套。用组合模式设计单元格结构求合计值就是递归相加。表达式引擎表达式本身就是递归定义的。一个加减表达式由数字、运算符、子表达式组成。我们可以设计一个 ExpressionNode 接口NumberNode 实现叶子求值OperationNode 实现递归求值。这是解释器模式常见的实现基础而组合模式提供了结构骨架。表单设计器表单里有输入框、下拉框、还有容器比如字段集、分组框容器里又能放任意控件。渲染表单统一调用 render()校验输入统一调用 validate()每次都不需要判断控件类型新加一个空间类型也无缝接入。这些场景有一个共性客户端需要无差别地处理单个对象和对象集合。找到这个共性你就能判断是否该上组合模式。5.2 组合模式和访问者模式搭配使用组合模式有一个天然的软肋如果你想在树上增加一个新操作比如导出Excel、生成JSON只能给每个节点类加方法。改的节点越多代码侵入越强。这时候可以把访问者模式请出来。组合模式提供树的稳定结构访问者模式把操作从节点类里抽离出来。你定义一个 Visitor 接口里面有 visit(Category) 和 visit(Product)每个节点实现accept(Visitor v)递归遍历时自动调用对应的 visit 方法。以后要加新操作写一个新 Visitor 就行节点类完全不用改。这种组合为骨、访问者为魂的搭配在报表引擎、规则引擎里非常常见。如果你发现要在组合模式树上频繁增加横向操作我强烈建议引入访问者。5.3 什么时候不该用组合模式组合模式虽好但它不是一个万能模式用错了反而让代码更难维护。层级非常浅且固定比如只有两层分类-商品不存在分类套分类。这种场景用两个独立的类就够了强行上组合模式只会增加抽象复杂度。叶子节点类型差异过大如果叶子节点之间的行为差异极大接口只能被迫声明一堆方法叶子节点的实现里全是空方法或抛异常组合模式就成了接口污染。树结构频繁变化且并发高组合模式对树结构的修改操作通常不是线程安全的如果高并发场景下需要频繁 add/remove你要额外加锁或引入不可变树方案复杂度会大幅上升。选择模式最重要的是性价比。如果简单嵌套结构用 if-else 就可以那就别为了用设计模式而用设计模式。组合模式的优势一定是在深度嵌套 需要统一操作 结构可能扩展三者的交集里才会完全释放。说了这么多最后分享一点个人经验。我上手组合模式时走了一些弯路最大的体会是不要急着把所有的树都变成组合模式要先把统一操作找出来。如果一棵树只有遍历一个操作组合模式的收益不够明显一旦你发现在三个不同的地方都对这棵树做递归聚合操作组合模式就会带来质的提升重复代码会快速收缩。另一个建议是从最简单的叶子节点开始写先让单个商品节点的行为正确再写容器节点。容器节点的递归逻辑一旦写好叶子节点再多也不怕。调试时打印缩进树结构是检查递归正确性的最直观方法我在实盘项目里一直靠这个快速定位递归边界问题。组合模式看着简单真正用好还是需要不少手感。希望这篇文章能帮你把这个模式用得明明白白少踩几个我当年踩过的坑。
