组合模式未直接解析Java Collection体系，但其“统一个体与容器操作”思想解释了Collection接口的统一性；Collection虽不提供树形管理方法，却通过add()、size()等契约践行组合精神，而真正需要嵌套语义时需自定义Composite结构。

组合模式本身并不直接解析 Java 的 Collection 体系，它和 Collection 接口及其子类（如 ArrayList、LinkedList）没有继承或实现关系。但它的设计思想——“统一个体与容器的操作”——恰好能帮你理解为什么 Collection 体系在使用上如此一致，也反向说明：Java 集合框架虽未按组合模式严格建模，却在接口契约层面践行了其核心精神。

为什么 Collection 接口天然体现组合模式逻辑

Collection 是所有单元素集合（如 HashSet）和可嵌套结构（如树形集合的自定义实现）的统一入口。它不区分“你存的是一个对象”还是“你存的是一个装满对象的容器”，只要实现了该接口，就能调用 add()、size()、iterator() 等方法：

• 个体变量（如单个 String）通过 add("hello") 加入集合，是“叶子”语义
• 容器对象（如另一个 Collection）也可被整体加入：mainList.addAll(anotherList)，此时它作为“子组合”参与操作
• 客户端代码无需判断 anotherList 是 ArrayList 还是 TreeSet，更不用管它内部是否嵌套了其他集合——只要它是 Collection，就支持统一遍历与聚合

Collection 体系未采用标准 Composite 结构的原因

标准组合模式要求 Component 明确定义 addChild()、getChild() 等树形管理方法，而 Collection 接口只关注“容纳元素”这一行为，并不承诺层级关系或递归结构：

• Collection 不提供 addSubCollection() 或 getChildren() 方法，它不负责构建树，只负责扁平化存储
• 像 TreeSet 或 ConcurrentSkipListSet 虽内部用树实现，但对外仍表现为线性集合，不暴露父子节点概念
• 真正需要组合模式的场景（如文件系统、UI组件树），开发者会自己定义 FileSystemItem 或 UIComponent 接口，而非复用 Collection

何时该自己实现 Composite，而不是依赖 Collection

当你面对的数据具有明确的“部分-整体”嵌套语义，且需对整棵树做统一操作时，Collection 就不够用了，必须手写组合结构：

• 要计算一个目录总大小，需递归调用每个子文件夹的 size()，而不仅仅是遍历 List<file></file>
• 要禁用整个菜单栏，包括所有子菜单和菜单项，不能只对 List<menuitem></menuitem> 调用 setEnabled(false)，因为子菜单本身也是可禁用的容器
• 要序列化/渲染一棵组织架构图，员工（Leaf）和部门（Composite）必须共享同一接口，才能被同一个遍历器处理

Collection 和 Composite 的协作方式

实际开发中，二者常配合使用：用 Collection 存储子节点列表，用自定义 Composite 类封装树形逻辑：

• Composite 类内部通常持有一个 Collection<component></component> 字段（如 private List<component> children = new ArrayList();</component>）
• 添加子节点调用 children.add(child)，删除调用 children.remove(child)，这正是借用了 Collection 的成熟能力
• 但关键的 operation() 行为（如 draw()、getSize()）由 Composite 自己递归实现，不依赖 Collection 接口