不是聚合或组合的UML关联？

Question

有人能给出一个UML关联关系（单向箭头 ->）的代码示例，既不是聚合也不是组合吗？

我知道聚合和组合是关联的类型，但我想不出一个既不是聚合也不是组合的关联关系。

在某些条件下，以下代码是否可以仅是A->B的关联关系，而不是聚合或组合？

import B;
public class A {
  private B b;
}

- Nemo

Answer 1

当你改变符号所代表的意义时，一个人（A）就可以驾驶（b）一辆汽车（B），而且无需组合或聚合它。

- Jim L.

Answer 2

根据Robert Martin的说法：

关联表示一个实例向另一个实例发送消息的能力。通常使用指针或引用实例变量实现，但也可以作为方法参数或创建本地变量来实现。

代码如下：

public class A {
  private B b;
}

可以表示关联、聚合或组合。只要A与B没有“HAS-A”关系，它就代表一个简单的关联关系。例如，下面的内容可能是一种关联关系，但不是聚合或组合关系。

public class Vehicle {
  private Person owner;
}

- softwarematter

---

拥有一辆车意味着聚合，这就是为什么我在我的简短回答中使用了“驾驶”的原因。 - Jim L.

Answer 3

今天早上我有一个突然领悟的时刻：

关联意味着本身加上聚合和组合，有时我们看到这三个被表示为：

关联

- 聚合 - 组合

在UML中还有另一种称为继承或派生的关系。

因此，整个概念或事物的层次结构是：

关系：2种（其中关系意味着将两个或多个集合中的事物相互关联，甚至是同一集合中的两个事物...内部关系因此在SQL中由两个相关联的事物组成）

继承：isA类型

关联：hasA类型

关联：（关系类型）

- 聚合：关联类型 - 组合：关联类型

继承类型意味着自上而下的特殊化和自下而上的概括。

在聚合和组合的概念中，都嵌入了所有权的概念...这意味着在一段时间内（临时情况：聚合）或整个生命周期（情况：组合）中，一个集合的元素是或被聚合器或组合器所拥有，技术上另一个集合对其具有引用。

换句话说，使用组合时，组合体永远不存在于组合器的上下文之外，并随其“死亡”...也就是创建引用由组合器拥有。

聚合和组合概念之间存在隐藏的继承关系，与关联相比...

也就是说，两者都是一种关联...因此使用缩进、父子关系表示...

但有一个术语常常让我感到困惑，我们称关联类型的关系为“hasA”！

但有时它没有意义。驾驶汽车的司机就是一种既不属于聚合也不属于组合的关联。没有所有权，这是三种关联中最松散的一种。在这种情况下，我们仍然可以说汽车有一个司机...

现在考虑一个人的联合体。没有其他人，这没有意义！ 它是联合体本身对相关人员的引用...就像vue.js中的模板标签或react中的<>（称为片段）...潜在地，关系可以在其任何参与者不知情的情况下实现...无论是所有者还是非所有者的司机都要负责... 整个联合体形成了一个具体实体...它对其参与者有引用...在法律术语中，它形成了一个单一的法律实体...它是调解员的原型，而聚合和组合则是观察者模式的原型...

为什么没有人像这样写呢？这太模糊了...

最后一句话，组合也是误导性的，在口语中，组合并没有这种独特的含义，例如花卉组合...任何组成部分都可以独立存在，这是一个联合体...但它总是可以被视为聚合，其中聚合器在外面！这就是联合体的含义，也正是我们可以说“拥有”的原因！

- miguel ibaretaras