组合要求整体销毁时部分必须销毁，通常构造器内new成员且无setter；聚合允许部分独立存在，常通过参数传入或提供setter。UML中实心菱形表组合、空心表聚合，需标注正确多重性。
聚合和组合在代码里到底长什么样
Java 本身没有 aggregation 或 composition 关键字，它们是设计意图，靠成员变量的生命周期管理和创建方式体现。
关键区别就一条：组合要求“整体销毁时，部分必须跟着销毁”；聚合则允许“部分独立存在”。这直接反映在构造、赋值和 finalize（或现代等效逻辑）中。
- 组合：通常在构造器里
new出成员对象，不对外暴露 setter，也不接受外部传入的已有实例 - 聚合：常通过参数传入已存在的对象，提供 setter，允许同一对象被多个“整体”引用
- 误用组合写法却让外部持有子对象引用，等于悄悄退化成聚合——UML 图再准，代码没约束就白画
示例：Car 和 Engine 是组合（Engine 随 Car 实例一起 new，不共享）；Department 和 Employee 是聚合（Employee 可属于多个部门，也能独立存在）。
UML 类图里菱形箭头怎么画才不翻车
空心菱形是聚合，实心菱形是组合——但很多人只记形状，忘了标注多重性（multiplicity）和方向，结果图和代码对不上。
立即学习“Java免费学习笔记（深入）”；
- 聚合箭头必须从整体指向部分，且部分端应标如
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 跳转像迷宫——得在可维护性和可读性之间卡好点
真正难的不是画对菱形，是每次加字段前想清楚：这个对象，是我造它，还是我找它？造它就得负责它的一生，找它就得接受它有自己的活法。
