1. 嵌套菜单的痛点为什么需要组合模式做Java开发这几年有个场景几乎人人都会撞上后台管理系统的菜单一个一级菜单下面挂着一堆二级菜单二级菜单下面可能还有三级菜单或者是文件管理器文件夹里套文件、套文件夹层数还完全不确定。我第一次正儿八经被这种结构恶心到是在一个电商后台权限模块里。当时的产品经理提了个需求菜单要支持无限层级页面上要能递归渲染权限树要能一键勾选所有子节点。我第一版用if-else写了个遍历方法本地测得好好的一上线遇到个四层菜单就崩了也不是报错就是其中有个菜单少渲染了两个节点。后来查了半天发现是递归方法里有一层返回类型写死了子节点丢了一截。这种部分和整体需要一致对待的场景正是组合设计模式要解决的。组合模式的核心思想是把单个对象和组合对象放进同一个继承体系里让客户端在使用时根本不用区分“我操作的是一个文件还是一个文件夹”“我处理的是一个菜单项还是一个菜单树”。这种结构在《设计模式可复用面向对象软件的基础》里属于结构型模式英文叫Composite Pattern。我最早看《大话设计模式》里那个“公司管理”例子时觉得这不就是把节点抽象一下嘛有什么好“模式”的。直到自己真去写一个带权限的菜单体系时才发现抽象得对不对、遍历稳不稳、增删节点会不会污染父类这些坑全在细节里。所以这篇想把组合模式掰开揉碎讲清楚核心结构是什么UML怎么画两种变体——透明式和安全式——到底怎么选JDK里哪些地方在用它以及我自己踩过的那些雷。适合谁来读准备Java面试的被问到“组合模式用过吗”时能答出点真东西正在自研权限系统、规则引擎、树形表结构想把代码写干净的还有读源码时看到Composite字眼一头雾水的。这篇不搞念概念、背定义那套直接给你能抄的代码和能复现的坑。2. 组合模式核心结构拆解与UML解读2.1 三个核心角色各自承担什么职责组合模式的结构说穿了就是三样东西抽象构件Component、叶子构件Leaf、容器构件Composite。抽象构件是整个模式的地基。它定义了一组通用的方法接口既包括业务方法也包括管理子节点的方法。注意“管理子节点”这几个字非常关键——文件有“重命名”“复制”这种业务方法文件夹也有这两个方法但文件夹还能“添加成员”“删除成员”文件不能。如果抽象构件里压根不定义add、remove这些方法那Leaf就不用实现一堆空方法了但客户端调用时就得先用instanceof去判断节点类型才能决定能不能往里塞子节点。这个矛盾就是后面透明式和安全式两种变体的根源。叶子构件是树形结构里没有子节点的那个末端。它实现真正的业务逻辑但add、remove这些方法对它没有意义。在透明式设计里Leaf会抛UnsupportedOperationException或者留空在安全式设计里Leaf根本不会暴露这些方法。容器构件是文件夹、菜单组这种可以挂子节点的存在。它内部通常维护一个List存储子节点add、remove、getChild方法是它的主战场。业务方法要递归调用所有子节点的同名方法这样一次操作就能波及整棵子树。画成文字版UML大概是这样的┌──────────────────────┐ │ interface/抽象类 │ │ Component │ ├──────────────────────┤ │ operation() │ │ add(c:Component) │ │ remove(c:Component) │ │ getChild(i:int) │ └──────┬──────────┬────┘ │继承 │继承 ┌──────────┴──┐ ┌───┴──────────────┐ │ Leaf │ │ Composite │ ├─────────────┤ ├──────────────────┤ │ operation()│ │ -children:List │ │ add()抛异常 │ ├──────────────────┤ │ remove()… │ │ operation() │ │ │ │ add() 实现 │ │ │ │ remove() 实现 │ │ │ │ getChild() 实现 │ └─────────────┘ └──────────────────┘依赖关系就一条Composite聚合了Component用List持有子节点Leaf和Composite都实现Component。2.2 为什么这个结构能把“单个对象”和“组合对象”拉到同一个维度这个问题我当年想了挺久。关键在于客户端代码面对的类型是Component而不是Leaf或Composite。拿菜单系统举例。用户点了一个菜单项它可能带子菜单也可能是不带子菜单的最终动作。如果我让MenuItem和Menu都实现MenuComponent接口那在渲染页面时代码只需要写一遍for (MenuComponent comp : menuComponents) { comp.render(); // 不管它是Menu还是MenuItem都会把自己渲染到页面上 }render()在MenuItem里输出自己的链接在Menu里输出自己头部、然后递归调用所有子节点的render()。客户端根本不用关心自己拿到的是叶子还是容器。这种“单个对象和组合对象一致性”的价值在业务代码里体现为大幅减少判断分支。权限树勾选、全选/取消全选、统计某菜单下所有按钮数量写法高度统一。如果你写过没有组合模式的版本应该能立刻感受到差异。那时你在遍历树时每拿到一个节点都得问它有子节点吗子节点是文件还是文件夹然后写两个不同的处理方法。组合模式的意义不是性能优化而是结构优化把客户端从“区分叶子/容器”的泥潭里解放出来。2.3 方法的递归传递是组合模式的心脏组合模式看起来就是“抽象类 子类 集合”真正让它发挥威力的是递归。Composite的operation()方法会遍历children逐个调用子节点的operation()。如果子节点是Composite它会继续往深层传递如果子节点是Leaf就执行到真正的业务逻辑。整个层级遍历是自动完成的不需要外层代码去写while或者for。这里有个容易被忽略的细节叶子与容器的边界。在组合模式里“叶子”不是一个绝对概念——今天这个Leaf明天需求变了下面要挂子节点它就得改成Composite。抽象构件定义统一的接口正是为了这种“角色转换”不摧毁调用方代码。只要客户端面向Component编程树结构调整是内部事务对外完全不感知。3. 透明式与安全式两种变体的取舍写组合模式时最难拿捏的不是递归而是add、remove这些管理方法放在哪个层级。不同的放法派生出了两种经典变体透明式Transparent和安全式Safe。两者没有绝对优劣选择题本身就是面试官爱挖的考点。3.1 透明式的实现与表面上的“省心”透明式的做法是把add、remove、getChild这些方法全定义在抽象构件Component接口里Leaf和Composite都强制实现。Leaf里add、remove直接抛异常getChild返回null或者抛异常。public abstract class MenuComponent { public void add(MenuComponent component) { throw new UnsupportedOperationException(叶子节点不支持添加); } public void remove(MenuComponent component) { throw new UnsupportedOperationException(叶子节点不支持删除); } public MenuComponent getChild(int i) { throw new UnsupportedOperationException(叶子节点没有子节点); } // 业务方法 public abstract void render(); }好处是客户端没有任何类型判断拿着MenuComponent就能一视同仁地调用所有方法。至少在代码层面叶子也能调用add——虽然运行时会抛异常。坏处是把“会出错的方法”暴露给了客户端调用方得知道哪些节点能调哪些会炸反而需要try-catch或内部约定不然就是运行时炸弹。3.2 安全式的实现与类型判断之痛安全式的做法是Component只定义业务方法把add、remove、getChild这些管理方法下沉到Composite子类。Leaf里压根不存在这些方法。public abstract class MenuComponent { public abstract void render(); } public class Menu extends MenuComponent { private ListMenuComponent children new ArrayList(); public void add(MenuComponent component) { children.add(component); } public void remove(MenuComponent component) { children.remove(component); } public MenuComponent getChild(int i) { return children.get(i); } Override public void render() { // 渲染自己和子节点 } }好处是类型安全Leaf上不存在会抛异常的方法编译期就能拦掉大量误调用。坏处是客户端在需要拼装树时得先判断类型if (component instanceof Menu) { ((Menu) component).add(new MenuItem(下单)); }这种instanceof的出现把“客户端不区分叶子/容器”的组合模式核心价值打了一个折扣。树越深这种判断语句越让人头大。3.3 实际项目中怎么选说实话真实项目里透明式用得更多。不是因为它的设计更优雅而是透明式让循环和递归代码极度干净——遍历时不用类型判断递归时只管传递。面试里经典问题“组合模式两种实现方案的区别”回答的落点也在这里透明式以代码整洁换取运行时风险安全式以类型安全换取类型判断。我的建议分场景如果你写的是框架、公共组件、API调用方是外部团队优先安全式。编译期报错远比线上运行时抛UnsupportedOperationException好。如果你写的是内部业务系统树结构自己维护调用方就是自己团队透明式省事得多。如果你的业务树中叶子节点非常稳定几乎不可能升级成容器安全式更合适如果节点随时可能从叶子变容器透明式方便扩展。下表快速对照对比项透明式安全式管理方法定义位置ComponentCompositeLeaf是否暴露add/remove是但运行抛异常否编译期不存在客户端是否需要类型判断不需要需要instanceof代码整洁度高低类型安全性低运行时异常高编译期拦截典型应用内部系统、框架内部对外API、公共组件4. 亲手实现一个文件系统完整代码与关键解析概念听得再多不如手写一遍。我用文件系统场景来个完整实现采用透明式写主体再演示怎么改成安全式。文件系统是组合模式最经典的映射文件夹Composite可以装文件Leaf和子文件夹文件是末端节点。4.1 抽象构件FileSystemNodepublic abstract class FileSystemNode { protected String name; public FileSystemNode(String name) { this.name name; } // 业务方法显示节点信息 public abstract void display(String prefix); // 管理子节点的方法透明式统一暴露 public void add(FileSystemNode node) { throw new UnsupportedOperationException(当前节点不支持添加子节点); } public void remove(FileSystemNode node) { throw new UnsupportedOperationException(当前节点不支持删除子节点); } public FileSystemNode getChild(int index) { throw new UnsupportedOperationException(当前节点没有子节点); } public String getName() { return name; } }在JDK 8以后的现代写法里FileSystemNode可以直接用interface加default方法实现同样效果。abstract class的好处是可以放name字段和getName()方法子类不用重复写。习惯接口风格的话也能把name放到实现类里看团队规范。4.2 叶子构件Filepublic class File extends FileSystemNode { private long size; // 单位字节 public File(String name, long size) { super(name); this.size size; } Override public void display(String prefix) { System.out.println(prefix name ( size bytes)); } public long getSize() { return size; } }File只实现真正的业务方法。display里把文件信息打印出来getSize返回大小。add、remove、getChild全部继承自抽象类调用时会抛异常——这就是透明式的特征。4.3 容器构件Directoryimport java.util.ArrayList; import java.util.List; public class Directory extends FileSystemNode { private ListFileSystemNode children new ArrayList(); public Directory(String name) { super(name); } Override public void add(FileSystemNode node) { children.add(node); } Override public void remove(FileSystemNode node) { children.remove(node); } Override public FileSystemNode getChild(int index) { return children.get(index); } Override public void display(String prefix) { System.out.println(prefix name /); for (FileSystemNode child : children) { child.display(prefix ); } } public long getTotalSize() { long total 0; for (FileSystemNode child : children) { if (child instanceof File) { total ((File) child).getSize(); } else if (child instanceof Directory) { total ((Directory) child).getTotalSize(); } } return total; } }注意到display的写法没有吗它把“显示自己”和“递归显示所有子节点”合在同一个方法里。process在面对整个Directory时天然波及所有后代。如果有人往Directory里塞了一个新的Filedisplay自动多渲染一行不需要改主逻辑。getTotalSize我特意用了instanceof判断想说明一个事不是所有方法都需要绕过类型判断某些聚合统计场景里类型判断反而更直白。设计模式的目的是让代码更好改不是为了让代码看起来“纯粹”。4.4 组装和调用public class CompositeDemo { public static void main(String[] args) { Directory root new Directory(项目资料); File readme new File(README.md, 2048); Directory src new Directory(src); Directory main new Directory(main); Directory javaDir new Directory(java); File application new File(Application.java, 4096); File config new File(application.yml, 1024); javaDir.add(application); javaDir.add(config); main.add(javaDir); src.add(main); root.add(readme); root.add(src); root.display(); System.out.println(总大小: root.getTotalSize() bytes); } }跑一下输出类似 项目资料/ README.md (2048 bytes) src/ main/ java/ Application.java (4096 bytes) application.yml (1024 bytes) 总大小: 7168 bytes这段代码里root.display()只用了一次调用就渲染了整棵树。你不需要知道树有多深、里面有几个文件夹组合模式替你完成了全部递归遍历。这就是组合模式“对客户端隐藏内部结构”的最直观体现。4.5 从透明式改造成安全式需要动哪里安全式改动很小FileSystemNode里删除add、remove、getChild方法只留display和getName。Directory子类自己声明这三个方法内部逻辑不变。客户端构建树的地方保持不变因为Directory的方法本来就在但只要你拿的是FileSystemNode引用就没法调用add了。FileSystemNode fakeContainer new File(fake.txt, 1); // fakeContainer.add(...); // 编译就报错不存在add方法这个改动看起来简单但它改变了调用方的编码约束安全式要求你在“加子节点”前必须知道类型。如果你用List 存放所有节点在遍历构建时就得写if (node instanceof Directory) { ((Directory) node).add(child); }少了透明式的随意多了代码上的确定性。怎么选回到第3节说的那些维度去权衡。5. JDK与主流框架中的组合模式很多人以为组合模式只出现在自己写的业务代码里实际上JDK和主流框架里到处都是它。读懂这些源码案例面试时讲组合模式就不飘了。5.1 HashMap 的 putAll 设计HashMap的putAll(Map? extends K, ? extends V m)接收的是另一个Map然后内部把每个键值对put进去。从组合模式视角看Map是ComponentHashMap和TreeMap都是具体构件。客户端调用putAll时不需要知道对方是HashMap还是TreeMap统一按Map处理把“整体”另一个Map当作“部分”一个个键值对来对待。这种“把一个整体拆成元素循环插入”的思路是组合模式思想在集合框架里的应用只是没严格套用“树形递归”那种结构。5.2 JSF 的 UIComponent 体系JavaServer Faces里UIComponent是所有UI组件的基类UIOutput、UIInput是叶子组件UIViewRoot、UIGroup这类容器组件可以持有子组件列表。页面渲染时UIViewRoot.renderAll(facesContext)会递归触发整棵组件树渲染。这不就是典型的安全式组合模式嘛容器有getChildren()和getFacets()方法叶子没有。Servlet规范里的FilterChain也有点那意思每个Filter处理完调用chain.doFilter往下传相当于一个“责任链版本的组合遍历”。5.3 MyBatis 的 XML 配置节点解析MyBatis解析mybatis-config.xml时会把整个文档解析成Configuration对象XML节点嵌套关系对应配置项父子关系。严格来说MyBatis解析使用的是解析器模式Parser 建造者模式Builder 组合思想但XML节点的层层递归解析逻辑和组合模式同构。读到源码里那些递归遍历子节点的逻辑时想明白它底层是对“节点”这个复合结构做组合遍历源码就好懂了。5.4 学到哪些设计思想从JDK这些案例里能提炼出组合模式的三个适用特征业务模型天然是树形的比如菜单、文件、组织架构、UI组件。客户端希望对单个对象和组合对象“一视同仁”统一遍历、统一操作。节点数量、层级深度不确定需要新增节点类型时不影响已有调用代码。凡是你看到“节点”“条目”“Tab”“菜单树”“分类树”这类名词第一个该想到的设计模式就可以是组合模式。6. 组合模式实战中的经验与陷阱组合模式写起来看着简单真正用到生产环境有几个坑是必然要踩的。下面几条全是我或身边同事的实盘经历挨个说透。6.1 深层递归的性能问题递归深度和栈溢出组合模式的业务操作靠递归传递树形结构层数过多时会撑爆JVM方法栈。我有个同事做组织架构解析导出一家一万人的公司时树深大概12层左右直接StackOverflowError。处理办法有几个限制层级深度做管理后台菜单其实很少有超过5层的真实业务需求产品要“无限层级”多是伪需求。可以在构建树时校验depth超限就拒绝。递归转循环某些聚合统计场景下可以把递归改成显式栈进行先序遍历避免方法栈开销。public void displayIterative(Directory root) { StackFileSystemNode stack new Stack(); stack.push(root); while (!stack.isEmpty()) { FileSystemNode node stack.pop(); node.display(); if (node instanceof Directory) { ListFileSystemNode children ((Directory) node).getChildren(); // 逆序入栈保证原有顺序 for (int i children.size() - 1; i 0; i--) { stack.push(children.get(i)); } } } }显式栈不会消除深层遍历本身的耗时但避免了方法调用栈溢出。还有个思路是JDK的Xss参数调大线程栈但这只是延迟爆炸不是根治。6.2 环引用问题父子互相引用组合模式里如果把一个父节点塞进自己的子孙节点里遍历会无限循环。比如Directory root new Directory(root); Directory child new Directory(child); root.add(child); child.add(root); // 灾难display时root会无限递归。生产环境这种Bug不是程序员故意造环更多是数据源里脏数据导致的比如从数据库中查询菜单表父子ID发生循环代码没有防御一渲染就卡死。建议在add方法里加校验Override public void add(FileSystemNode node) { if (node this) { throw new IllegalArgumentException(不能将自身添加为子节点); } if (node instanceof Directory isDescendant((Directory) node)) { throw new IllegalArgumentException(不能添加自身派生的节点会形成环); } children.add(node); } private boolean isDescendant(Directory node) { for (FileSystemNode child : children) { if (child node) { return true; } if (child instanceof Directory ((Directory) child).isDescendant(node)) { return true; } } return false; }虽然这个校验本身也是递归但它把环问题挡在了入树之前。数据库导入时有脏数据第一层校验就能拦下来。6.3 拷贝、序列化与HashCode的循环依赖坑树形结构是引用链深拷贝时如果不处理环引用会一直递归到栈溢出。序列化成JSON时Jackson、Gson默认对循环引用直接抛异常或产生无限递归。实际项目里用组合模式做菜单树经常要把它转成JSON给前端渲染父子互相引用时直接序列化会把你气死。处理方案用Jackson的JsonIdentityInfo注解管理对象标识让同一对象在序列化时复用ID而不是展开两次。或者转成DTO用一维列表parentId表示树前端自己组装彻底绕开循环引用。我个人更推荐后者。树形结构做传输载体本身容易出问题DTO之间用parentId关联序列化、分页、搜索都方便得多。6.4 真正该用组合模式时的信号写代码时怎么判断要用组合模式三个信号代码里出现“某个方法在处理单个对象和集合对象时逻辑几乎一样”。遍历树时到处是“如果它是叶子就怎样如果它是容器就怎样”的if-else。来了新节点类型比如文件夹里要放快捷方式要改很多方法签名或case分支。反过来如果树结构很浅、固定只有两层或者节点类型差异太大没法抽象公有方法那就不要为了模式而模式。组合模式不是银弹用一个普通数组加个for循环可能更合适。踩过几次坑之后我自己写树形结构养成一个习惯无论采用组合模式与否先问自己这个树会不会变深、会不会涉及环、会不会被序列化出去。想清楚这三个问题再决定要不要让代码面向组合模式设计。
