UML类图Order等类间聚合/关联/依赖关系判定疑问

疑问点 #

针对图中的关系标注，存在两点疑问：

• 为什么Order（订单）与OrderDetail（订单明细）之间是聚合（aggregation）关系？Order类中仅定义了List<OrderDetail>类型的orderDetails成员，对应代码如下，二者为什么不是普通关联（association）关系？

public class Order{
    public DateTime date;
    public Status status;
    public List<OrderDetail> orderDetails;
}

• 为什么OrderDetail（订单明细）与Item（商品）之间是依赖（dependency）关系？OrderDetail类持有Item类的引用，二者为什么不是关联关系？

问题解答 #

关于Order与OrderDetail的聚合关系判定 #

首先要明确：聚合本身就是关联的一种特殊类型，专门用来描述整体-部分的has-a关系，且整体和部分的生命周期不严格绑定。
业务逻辑上，订单明细天生就是订单的组成部分，完全符合整体-部分的语义：不存在脱离订单独立存在的订单明细，但订单明细不会和订单实例完全绑定生命周期——比如订单被逻辑删除、归档后，明细数据依然可以单独留存用于销售统计、售后溯源，不会跟着订单实例一起失效，因此标注为聚合是符合业务语义的。
普通关联没有这种强整体-部分的从属属性，比如用户和配送地址的关系就属于普通关联，不存在谁是谁固定组成部分的说法，和订单-订单明细的从属逻辑有本质区别。

关于OrderDetail与Item的依赖关系判定 #

关联和依赖的核心判定边界非常清晰：关联是类结构层面的长期强关系，要求类将对方作为成员变量长期持有引用；依赖是运行期的临时弱关系，不需要长期存储对方的引用，通常出现在方法传参、局部变量、静态方法调用这类临时使用对方的场景中。
认为OrderDetail持有Item引用就属于关联，是混淆了代码实现表象和UML语义的对应关系：在这个订单模型里，OrderDetail根本不会把Item作为成员变量长期持有引用——毕竟商品的名称、价格、状态随时可能变动，订单明细只需要在生成的瞬间临时读取Item的信息存储快照（如下单时的商品名、交易单价），后续就算商品被删除、调价，明细里的快照信息也不会发生变化，完全不需要长期绑定Item实例的引用。二者仅在生成明细、核对交易信息的场景下临时产生交互，因此属于依赖关系，而非关联。

内容的提问来源于stack exchange，提问作者ELOL