在面向对象分析与设计（OOAD）的领域中，定义对象之间的交互方式与定义对象本身同样重要。在各种结构关系中，组合是一种强化严格所有权和生命周期依赖关系的机制。在建模复杂系统时，选择使用组合而非简单的关联或聚合，从根本上改变了数据流动方式以及内存管理方式。
本指南探讨了类结构中组合关系的机制。我们将分析其理论基础、实际实现模式以及对系统架构的影响。重点始终放在结构完整性和逻辑一致性上，避免不必要的复杂性，同时确保设计的稳健性。
🧩 在OOAD中定义组合
组合是一种特殊的关联形式，表示“部分-整体”关系。与两个独立实体之间的普通连接不同，组合意味着部分无法脱离整体而独立存在。这种依赖关系是结构性的，而不仅仅是逻辑上的。
- 所有权： 组合对象拥有其组件的生命周期。
- 存在性： 如果整体被销毁，其部分也会随之被销毁。
- 可见性： 部分通常在整体的范围之外不可见。
考虑一个简单的层次结构。一个房屋类可能包含多个房间对象。如果房屋被拆除，那么房间对象在该上下文中就不再存在。它们不会自动迁移到另一栋房屋中。这就是组合的本质。
📊 组合与聚合的对比
组合与聚合之间常常产生混淆。两者都是关联的形式，但在生命周期管理和耦合强度方面存在显著差异。理解这一区别对于准确建模至关重要。
| 特性 | 组合 | 聚合 |
|---|---|---|
| 所有权 | 强所有权 | 弱所有权 |
| 生命周期 | 依赖 | 独立的 |
| 创建 | 由整体创建 | 外部创建 |
| 销毁 | 随整体一起删除 | 可以独立于整体存在 |
| 示例 | 心脏与身体 | 学生与大学 |
在聚合中，一个大学管理一个学生对象。如果大学关闭，学生仍然存在；他们只是转移到另一所机构。在组合中，一个身体管理一个心脏。如果身体死亡，心脏将不再作为活器官运作。
⏳ 生命周期管理与内存
组合的一个主要技术影响是内存如何被处理。在许多编程范式中，复合对象负责为其组件分配和释放内存。
- 分配：当复合对象被实例化时，它会实例化其各个部分。
- 释放：当复合对象被销毁时，它会递归地销毁其各个部分。
- 例外情况：如果需要外部访问，可能需要显式引用各个部分。
这种自动管理减少了内存泄漏和悬空指针的风险。然而，它引入了一定的僵化性，必须与聚合的灵活性进行权衡。如果一个部分需要在多个复合对象之间共享，组合通常不是一个合适的选择。
🛠️ 实现模式
实现组合需要仔细关注引用的传递方式。以下模式有助于保持关系的完整性。
1. 构造函数注入
最常用的方法是将组件实例传递给复合对象的构造函数。这确保了复合对象在缺少必需部分的情况下无法存在。
- 保证初始化状态。
- 如果属性是只读的，则强制引用的不可变性。
- 防止创建无效状态。
2. 封装访问
组件通常应被隐藏。提供一个返回部分引用的getter方法可能会破坏生命周期的封装性。如果客户端获得直接引用，他们可能会以损害整体的方式修改该部分。
- 使用返回副本或接口的访问器方法。
- 限制对部分对象的直接修改。
- 确保复合对象控制修改逻辑。
3. 递归销毁
当复合对象被移除时，系统必须确保所有嵌套的部分都被清理。在具有垃圾回收的语言中，这通常是隐式的。在手动内存管理中，复合对象必须显式地在其部分上调用销毁方法。
🔗 与设计原则的关系
组合与多个核心设计原则紧密对齐，这些原则指导着可维护的软件架构。
单一职责原则
组合鼓励将大型类分解为更小、更专注的组件。每个组件处理整体的特定方面。这种分离使代码更易于测试和修改。
开闭原则
通过组合行为而非继承，类可以在不修改现有代码的情况下进行扩展。你可以将一个组件替换为另一个实现相同接口的组件，从而动态地改变行为。
依赖倒置
高层模块不应依赖低层模块。两者都应依赖抽象。组合允许复合对象依赖于部分的接口，从而在不影响复合对象的情况下改变部分的实现。
🚧 常见挑战
尽管组合提供了稳健性，但它也引入了架构师必须应对的特定挑战。
- 循环依赖：如果两个复合对象相互引用，可能会形成一个循环，使生命周期管理变得复杂。打破这些循环通常需要引入中间层或使用弱引用。
- 测试复杂性：测试一个复合对象需要设置其内部结构。如果部分之间耦合紧密，模拟它们可能会很困难。
- 序列化：保存和加载对象图可能很棘手。反序列化的顺序很重要。通常需要先重建整体，再重建各部分。
- 性能开销：创建和销毁嵌套对象会增加计算成本。在高性能系统中，必须衡量这种开销。
🔄 重构聚合为组合
随着系统的发展，关系可能需要调整。一个常见的重构任务是在所有权变得明确时，将聚合转换为组合。
- 识别转变： 确定该部分现在是否应与整体一同被销毁。
- 更新生命周期逻辑： 确保复合对象承担起该部分销毁的责任。
- 审查引用： 移除允许独立存在的外部引用。
- 更新测试： 验证新的生命周期约束是否仍然成立。
相反，当某个部分必须被共享时，就需要从组合转向聚合。这涉及使该部分的创建独立于整体。
🌐 现实世界中的建模场景
让我们看看这如何应用于常见的领域模型。
场景1：文档管理系统
一个文档包含页面对象。如果文档被删除，页面将不再相关。此处适合使用组合。文档控制着页面的顺序和存在性。
场景2：电子商务订单
一个订单包含订单项对象。当订单被确认并归档时，这些项目仍作为历史数据保留。然而，如果订单被作废，这些项目将被移除。这表明在订单的活跃状态下应使用组合。
场景3：金融投资组合
一个投资组合持有资产 对象。资产通常存在于投资组合之外（例如，公开市场中的股票）。从投资组合中移除一个资产并不会摧毁该资产。此时，聚合是正确的选择。
⚖️ 决策框架
在决定是否实现组合时，请提出以下问题：
- 该部分在逻辑上是否仅属于一个整体？
- 如果整体被移除，该部分是否也应该停止存在？
- 该部分的创建是否依赖于整体？
- 我们是否需要对外部客户端隐藏内部结构？
如果对这些问题的回答始终是“是”，那么组合很可能是正确的结构关系。如果回答是“否”，则应考虑聚合或关联。
🛡️ 安全性与一致性
保持组合的一致性需要严格的验证。组合对象永远不应处于缺少必需部分的状态。这通常通过以下方式实现：
- 构造函数验证： 如果必需的部分为 null，则抛出错误。
- 不变式： 在修改前后检查条件。
- 私有字段： 将对部分的引用保持为私有，以防止外部篡改。
这种级别的控制确保了系统在整个执行过程中都处于有效状态。它防止了用户尝试访问不存在文档的页面等场景。
📈 可扩展性考虑
随着类的数量增加，组合树的复杂性也可能上升。过深的嵌套可能导致：
- 初始化时间过长。
- 难以导航的路径。
- 更难阅读的对象图。
设计师应尽可能采用浅层的层级结构。扁平化结构通常能提升性能和可维护性。如果一个组合包含另一个组合，请确保内部组合不是外部组合的实现细节。
🧪 测试策略
测试以组合为主的系统需要采用特定的方法。
- 单元测试： 使用模拟对象对组合部分进行隔离测试。
- 集成测试： 验证生命周期事件在整个对象图中是否能正确触发。
- 状态测试： 确保复合对象不能被修改为无效状态。
自动化测试应覆盖销毁路径，以确保没有资源泄漏。在内存资源有限的环境中，这一点尤为重要。
🔮 未来兼容的结构
在设计时考虑组合，可以为未来的变更做好准备。如果需求发生变化，允许部件共享，那么从组合转向聚合将是一个局部性变更。从继承转向组合则是一种结构性转变，通常能简化层次结构。
通过优先考虑组合，开发者能够构建出模块化且稳健的系统。明确的所有权模型减少了关于谁负责管理特定数据的歧义。