前面三篇(代理、装饰器、适配器)都是包装一个对象。从这一篇起,结构型模式换个话题——组织一群对象。第一站是组合模式(Composite),它专门对付一种特定的数据结构:树。树形结构在业务里无处不在:文件系统里,文件夹装着文件,文件夹里还能装文件夹;公司组织里,部门下有小组,小组下有员工;前端的 DOM 里,节点嵌套着节点。它们有个共同特征:存在单个元素和一组元素(容器)两种角色,而容器里又能装单个元素或更小的容器,层层嵌套。我们的订单场景也有这样的结构——一个订单里有商品,但有的商品其实是个套餐,套餐里又包含好几个子商品,子商品理论上还能再嵌套。处理这种结构,最头疼的是区别对待:你想算一个订单的总价,就得先判断这个元素是单个商品还是套餐?“——是商品就直接取价,是套餐就得遍历它的子项再累加,而子项里可能又有套餐……代码里到处是如果是叶子怎么办、如果是容器怎么办的判断,一旦嵌套深了,就是一团递归的乱麻。组合模式的核心价值,就是消灭这种区别对待:让你能用完全一致的方式,去处理一个商品和一整个套餐”,不用关心手上的到底是叶子还是容器。这篇文章按这条线索展开:先看区别对待带来的麻烦;再引出组合模式如何用一个统一接口抹平单个与一组的差异;然后讲清它的角色和那个关键的透明 vs 安全设计取舍;接着看它在标准库里的经典身影;最后给出适用边界。贯穿例是订单里的套餐嵌套。目录树形结构的麻烦:到处都在区别对待组合模式:让单个和一组长得一样角色、骨架与递归之美一个关键取舍:透明模式 vs 安全模式现实身影:树的地方就有它什么时候用组合模式一、树形结构的麻烦:到处都在区别对待先看订单里的套餐结构。一个订单可能是这样的:订单 ├── 商品:可乐 ×1 (单个商品) ├── 套餐:午餐套餐 (容器,里面还有子项) │ ├── 商品:汉堡 ×1 │ ├── 商品:薯条 ×1 │ └── 套餐:饮料组合 (容器里还嵌套容器) │ ├── 商品:咖啡 ×1 │ └── 商品:甜点 ×1 └── 商品:纸巾 ×1 (单个商品)现在要算这个订单的总价。如果不用组合模式,你得区分单个商品和套餐两种类型,代码大概长这样:doublecalcTotal(ListObjectitems){doubletotal0;for(Objectitem:items){if(iteminstanceofProduct){// 如果是单个商品total((Product)item).getPrice();}elseif(iteminstanceofComboPackage){// 如果是套餐// 得手动递归进去,把套餐里的子项再算一遍totalcalcTotal(((ComboPackage)item).getChildren());}}returntotal;}这段代码的问题很典型:调用方被迫知道元素有两种类型,并为每种写不同的处理逻辑(instanceof 分支)。不光是算总价,展示订单、统计商品数、导出清单……每一个操作都得重复这套判断类型 分别处理 手动递归的模板。一旦以后又多出一种容器类型(比如礼包),所有这些地方都得加分支。这违反了开闭原则,也让代码充满了易错的类型判断。问题的根源在于:在调用方眼里,单个商品和套餐是两种不同的东西,得区别对待。可如果我们退一步想——不管是单个商品还是套餐,它们对外都应该能回答同一个问题:“你多少钱?”。单个商品回答自己的价;套餐回答我所有子项加起来的价。如果它们能用同一个方法回答,调用方不就不用区分了吗?这正是组合模式的突破口。二、组合模式:让单个和一组长得一样组合模式的核心思想:让单个元素(叶子)和容器(组合)实现同一个接口,从而让调用方可以用一致的方式对待它们。容器在实现接口方法时,把请求转发给它的所有子元素——而子元素可能又是叶子或容器,于是天然形成递归。第一步,定义一个所有元素共同的抽象接口(叫组件):// 组件:叶子和容器共同的接口publicinterfaceOrderComponent{doublegetPrice();// 不管你是商品还是套餐,都得能回答多少钱voidprint(Stringindent);// 也都能打印自己}第二步,叶子节点(单个商品)——它没有子元素,直接返回自己的数据:publicclassProductimplementsOrderComponent{privatefinalStringname;privatefinaldoubleprice;publicProduct(Stringname,doubleprice){this.namename;this.priceprice;}publicdoublegetPrice(){returnprice;}// 叶子:返回自己的价publicvoidprint(Stringindent){System.out.println(indent商品:name ¥price);}}第三步,容器节点(套餐)——它持有一批子元素,把请求转发给每个子元素再汇总:publicclassComboPackageimplementsOrderComponent{privatefinalStringname;privatefinalListOrderComponentchildrennewArrayList();// 子元素publicComboPackage(Stringname){this.namename;}publicvoidadd(OrderComponentchild){children.add(child);}// 往容器里加publicdoublegetPrice(){doubletotal0;for(OrderComponentchild:children){totalchild.getPrice();// 转发给每个子元素,子元素自己会算}returntotal;// 递归的关键:不关心 child 是叶子还是容器}publicvoidprint(Stringindent){System.out.println(indent套餐:name);for(OrderComponentchild:children){child.print(indent );// 同样地转发}}}看ComboPackage.getPrice()里那行child.getPrice()——它压根不检查child是商品还是套餐,直接调getPrice()就完了。如果child是商品,返回商品价;如果是套餐,套餐自己又会去遍历它的子项……递归就这么自然地发生了,而代码里没有一个instanceof。现在用起来,构建和计算都清爽了:ComboPackagelunchnewComboPackage(午餐套餐);lunch.add(newProduct(汉堡,20));lunch.add(newProduct(薯条,10));ComboPackagedrinksnewComboPackage(饮料组合);drinks.add(newProduct(咖啡,15));lunch.add(drinks);// 套餐里嵌套套餐,没问题// 关键:算总价时,完全不区分它是商品还是套餐System.out.println(lunch.getPrice());// 45,内部递归自动算好对比第一节,升级点非常清晰:调用方不再需要instanceof和分支判断,面对任何一个OrderComponent,直接调getPrice()就行。单个和一组在调用方眼里长得一模一样了——这就是组合模式最核心的价值。三、角色、骨架与递归之美组合模式有三个角色:角色本例中是谁职责抽象组件(Component)OrderComponent接口叶子和容器的共同接口叶子(Leaf)Product没有子节点的终端元素容器/组合(Composite)ComboPackage持有子组件,把操作转发给子组件用一张树形图看这个结构最直观:图里最值得体会的是那条从容器指回抽象组件的引用(容器持有的是ListOrderComponent,而不是ListProduct)。正是这个容器持有的是抽象组件的设计,让容器既能装叶子、也能装容器,从而支持任意深度的嵌套。而所有操作(算价、打印、统计)都变成了对这棵树的递归遍历:遇到叶子就直接处理,遇到容器就转发给它的孩子——递归的终止条件(叶子)和递归步骤(容器转发)被优雅地分派给了两个不同的类,你甚至不用自己写if来控制递归,类型系统帮你搞定了。这就是组合模式的递归之美:把一个复杂的树形递归,拆解成每个节点各自简单的、局部的行为。四、一个关键取舍:透明模式 vs 安全模式组合模式有一个必须讲清楚的设计取舍,关于管理子节点的方法(add、remove)该放在哪。看个矛盾:add(child)、remove(child)这些管理子节点的方法,只有容器才需要——叶子是没有子节点的,给一个商品调add毫无意义。那这些方法,应该定义在抽象组件接口里,还是只定义在容器类里?两种选择,各有利弊,分别叫透明模式和安全模式:透明模式:把add/remove也放进抽象组件接口OrderComponent。好处:叶子和容器接口完全一致,调用方拿到任何组件都能一视同仁,真正做到透明——这也是 GoF 原书推荐的方式。代价:叶子(Product)被迫也实现了add/remove,但它其实不支持,只能空实现或抛异常。这就把不支持的问题从编译期推迟到了运行时——你给一个商品调add,编译不报错,运行时才抛UnsupportedOperationException。这其实违反了里氏替换(第一篇讲过的:子类不该抛父类不抛的异常)。安全模式:add/remove只定义在容器类ComboPackage里,抽象组件接口保持干净。好处:类型安全,叶子根本没有add方法,你在编译期就不可能对叶子误调用。代价:叶子和容器接口不一致了,调用方想调add时,必须先判断这是不是容器、并向下转型成ComboPackage——又回到了instanceof的老路,失去了部分透明。怎么选?这是透明性和类型安全之间的权衡,没有绝对答案:如果你更看重调用方完全不区分叶子和容器的极致透明(比如做一个通用的树遍历框架),选透明模式,接受叶子那几个空实现;如果你更看重编译期的类型安全、不希望出现对叶子调 add的运行时错误,选安全模式,接受调用方偶尔要做类型判断。实际项目里,透明模式用得更多,因为组合模式的全部意义就是统一对待,安全模式的类型判断某种程度上削弱了这个初衷。但要清楚它的代价,并在叶子的空实现里给出清晰的异常信息。理解这个取舍,比记住哪个更好更重要——它再次说明:模式不是死板的教条,而是一组需要你根据场景权衡的选择。五、现实身影:树的地方就有它组合模式在标准库和框架里,凡是有树的地方几乎都有它:java.awt/ Swing 的 UI 组件树:Component是抽象组件,Button、Label是叶子,Container(如Panel、Frame)是容器,容器里能放组件也能放容器。你调container.paint(),它会递归地把自己和所有子组件都画出来——标准的组合模式。XML/HTML 的 DOM 树:Node是抽象组件,文本节点是叶子,元素节点是容器,层层嵌套构成文档树。文件系统抽象:File既可以代表文件(叶子),也可以代表目录(容器),listFiles()递归遍历——虽然 Java 的java.io.File没有严格按组合模式设计,但思想一致。各类菜单树、权限树、组织架构树、评论嵌套回复:业务系统里凡是可无限嵌套的层级结构,组合模式都是标准解法。一个识别信号:只要你看到XX 里可以包含 XX,且能无限套下去,并且希望对单个和一组用统一方式处理,那就是组合模式的主场。六、什么时候用组合模式老规矩,泼冷水。组合模式很优雅,但它有明确的适用前提。适合用的信号:你的数据天然是树形/层级结构(部分-整体的关系,能无限嵌套);你希望用一致的方式处理单个对象和对象组合,不想在业务代码里到处instanceof判断类型;新增一种叶子或容器类型时,不想改动已有的遍历逻辑。不必用的信号:数据结构就是扁平的一层(比如订单直接挂一堆商品,永远不会嵌套)——那用普通的List遍历就够了,套组合模式纯属把简单问题复杂化;各种元素的行为差异极大、根本抽象不出一个统一接口——强行统一反而别扭。判断的核心仍是那句话:先确认数据真的是会嵌套的树,且真的需要统一处理单个与一组,组合模式才配得上。给一个永远只有一层的结构套上 Component/Leaf/Composite 三角色,是典型的过度设计。小结。组合模式专治树形结构,它让单个元素(叶子)“和容器(组合)“实现同一个接口,使调用方能用完全一致的方式处理它们,彻底消灭了区别对待和满地的instanceof。它的精髓是容器持有的是抽象组件”,从而支持任意深度嵌套,并把复杂的树递归拆解成每个节点简单的局部行为。它有透明模式(接口统一但叶子有空实现)和安全模式(类型安全但需类型判断)两种取舍,实际多用透明模式。Swing 组件树、DOM 树、文件系统,都是它的经典身影。下一篇我们讲外观模式——如果说组合是把一群对象组织成树”,那外观就是给一堆复杂的子系统盖一个简单的门面,让你一句话就能调动背后一整套复杂流程。