聚合与组合关系详解：UML类图基础

本文深入剖析了UML类图中聚合与组合这两种核心关联关系的本质区别与实践落地难点：组合强调“整体与部分生死与共”，要求部分由整体创建并独占，销毁时必须同步释放；聚合则体现“松耦合的拥有关系”，部分可独立存在、被多方共享。文章直击开发痛点——Java无语法强制，全靠设计意图在代码中体现，一旦构造方式、引用管理或依赖注入配置失当（如组合中暴露成员、聚合中标错多重性），UML图再规范也形同虚设；更进一步指出，选择组合还是继承的关键不在复用便利性，而在应对变化的能力——组合赋予灵活性，继承锁定本质。最终提醒开发者：每次声明成员变量前，都应回答一个朴素问题——“我是造它，还是找它？”答案决定了整个对象生命周期的设计契约。

聚合和组合在代码里到底长什么样

Java 本身没有 aggregation 或 composition 关键字，它们是设计意图，靠成员变量的生命周期管理和创建方式体现。

关键区别就一条：组合要求“整体销毁时，部分必须跟着销毁”；聚合则允许“部分独立存在”。这直接反映在构造、赋值和 finalize（或现代等效逻辑）中。

• 组合：通常在构造器里 new 出成员对象，不对外暴露 setter，也不接受外部传入的已有实例
• 聚合：常通过参数传入已存在的对象，提供 setter，允许同一对象被多个“整体”引用
• 误用组合写法却让外部持有子对象引用，等于悄悄退化成聚合——UML 图再准，代码没约束就白画

示例：Car 和 Engine 是组合（Engine 随 Car 实例一起 new，不共享）；Department 和 Employee 是聚合（Employee 可属于多个部门，也能独立存在）。

UML 类图里菱形箭头怎么画才不翻车

空心菱形是聚合，实心菱形是组合——但很多人只记形状，忘了标注多重性（multiplicity）和方向，结果图和代码对不上。

• 聚合箭头必须从整体指向部分，且部分端应标如 0..* 或 1..*；如果标成 1 却允许 null，就是逻辑矛盾
• 组合端不能标 0，因为“整体存在时部分必须存在”，所以至少是 1；若运行时可能为 null，那就不是组合
• 工具如 PlantUML 或 VS Code 插件生成图时，aggregation="shared" 和 composition="composite" 这类配置项容易填反，建议手写时直接查 UML 2.5 规范里的语义定义

为什么 IDE 不报错，但设计已经错了

因为聚合/组合是语义契约，不是语法约束。JVM 不管你是不是真销毁了子对象，只要没内存泄漏，代码就能跑。

• 常见错误：用组合声明（private final Engine engine = new Engine();），却在别处把 engine 暴露给其他类长期持有——这时 Car 销毁后 Engine 仍存活，实际已是聚合
• 另一个坑：用依赖注入（如 Spring）管理组合关系，但把 @Scope("prototype") 的 bean 注入到单例组件里，导致“组合对象”被多个整体共享，违背组合本意
• 静态分析工具（如 SonarQube）能检出部分问题，比如检测到 final 字段被反射修改，或发现某对象被多个容器强引用却标记为组合——但这需要额外规则配置，开箱即用默认不覆盖

什么时候该选组合而不是继承

不是“能不能用继承”，而是“变不变”。组合应对变化，继承表达本质。

• 如果子类只为了复用代码，且父类行为未来可能调整（比如 Logger 的输出方式要从文件切到 Kafka），用组合+策略接口更稳；硬继承会把实现细节锁死
• 继承适用于 is-a 关系明确、API 稳定的场景，比如 ArrayList 继承 AbstractList；而 Order “有”一个 PaymentProcessor，不是“是一种”处理器，必须用组合
• 注意：组合引入了间接层，调用链变长；过度拆分（比如每个字段都包一层类）会让调试时栈帧爆炸，IDE 跳转像迷宫——得在可维护性和可读性之间卡好点

真正难的不是画对菱形，是每次加字段前想清楚：这个对象，是我造它，还是我找它？造它就得负责它的一生，找它就得接受它有自己的活法。

今天关于《聚合与组合关系详解：UML类图基础》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！