作文不是 "Composition"
Composition is not "Composition"
Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
Deitel P.J., Deitel H.M。 - Java 如何编程第 9 版。
本主题讨论了这个观点：
Prefer composition over inheritance?
Composition: Composite aggregation (composition) is a "strong" form of aggregation with the following characteristics:
*it is binary association,
*it is a whole/part relationship,
*a part could be included in at most one composite (whole) at a time, and
*if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it.
发现于 http://www.uml-diagrams.org/composition.html
（实际上，Deitel 在同一本书中介绍了遵循这个想法的 UML 示例，但没有费心去解释不同之处）。
这个话题讨论了这个观点：
What is the difference between association, aggregation and composition?
很好，两者都是正确的。而这就引入了同音异义概念的问题。
例如：不要画一个带有复合箭头的UML模型来举例说明第一个定义：在UML中，任何关联都是由Deitels'第一个定义组成的。
以下是我的问题的一些方面，可能有助于正确回答：
我怎么能说（并知道）我们在谈论哪种作文？
我们在哪里划清两个定义之间的界限（在上下文中）？
我能说第一个是面向对象编程，第二个是软件吗engineering/modeling？
UML 组合是否只有模型concept/jargon？
UML组合是不是UML独有的东西？或者也应用在编程领域？
如何避免团队中“我们在谈论什么组成”的误解？
请回答参考文献和证据，这不是 philosophical/opinion 问题，这是我试图解决的“范围”问题。
而且这不是“什么是组合”的问题。
编辑：我在想区别是动词 x 形容词：“构成”class（第一个定义）和“复合关系”（第二个定义）。
引用第 110 页的 UML 2.5 规范：
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. To represent such circumstances, a Property has an aggregation property, of type AggregationKind; the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property. AggregationKind is an enumeration with the following literal values:
none: Indicates that the Property has no aggregation semantics.
shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
我个人认为复合聚合的概念是关于对象生命周期的，而不是关于静态关系的。 复合聚合 会在其父项死亡时杀死聚合成员。 None 保持打开状态。 共享聚合 是 OMG 根本不应该引入的混蛋，因为它的语义是域相关的。
我发现很难解释 UML 关联和实现引用之间的区别，而不至少解释一下 UML 关联实际上是什么，以及它们可以做什么，所以我们开始吧。
协会 & Link
让我们先看看 UML 关联和 link（关联的实例）是什么。
[11.5.3.1] An Association specifies a semantic relationship that can occur between typed instances.
[11.8.1.1] A link is a tuple of values that refer to typed objects. An Association classifies a set of links, each of which is an instance of the Association. Each value in the link refers to an instance of the type of the corresponding end of the Association.
所以下面是有限关联的有效实现。
class Brain { }
class Head { }
a = new Brain;
b = new Head;
link = (new Array).add(a).add(b);
所有权
[9.5.3] When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
（注意：Class 是 Class 化器的子class。）
适航性
[11.5.3.1] An end Property of an Association that is owned by an end Class or that is a navigableOwnedEnd of the Association indicates that the Association is navigable from the opposite ends; otherwise, the Association is not navigable from the opposite ends. Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.
为什么这些概念相关？想象一下下面的例子。
我们看到 brain 是 Head class 的属性（黑点表示对面 Class 的所有权），并且它是可导航的（箭）。
我们还看到 head 不是 Brain 的属性（没有黑点 ⇒ 不属于 Brain class ⇒ 不是 Brain 的属性），但是它仍然可以导航。这意味着在 UML 中 head 属性 由关联本身持有。
例如，实现可能看起来像这样（关联本身由两个引用的元组表示（请参阅前面的 link 描述））。
class Head {
public Brain brain;
}
class Brain {
}
h = new Head;
b = new Brain;
h.brain = b;
link = (new Array).add(h).add(b);
因此，正如您希望开始看到的那样，UML 关联并不是像 has-a 关系这样简单的概念。
作文
让我们再添加一块，合成。
[11.5.3.1] A binary Association may represent a composite aggregation (i.e., a whole/part relationship). Composition is represented by the isComposite attribute
[9.9.17] The value of isComposite is true only if aggregation is composite.
随着聚合
- none - Indicates that the Property has no aggregation semantics.
- shared - Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
- composite -- Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects
我们再次看到，UML 关联明确指定了难以从实现中感知的概念（例如，谁负责对象 management/destruction）。
模型组合与对象实现组合
因此，根据上面的描述，我们可以更准确地描述什么是实现组合（具有关系）。
[Deteils] Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
McConnell [Code Complete 2, 6.3] also refers to has-a relationship as a Containment.
但是他们都没有谈论如何对象（容器包含的，作曲家复合的）彼此相关，谁负责生命周期，或者包含的元素是否了解容器。
所以只要说对象有一种关系（并称之为组合），你实际上可以指这些中的任何一个（以及更多）
因此，如果您在编程中称某些东西为组合，您几乎可以指任何 relationship/reference（或者更确切地说不是继承），所以这个词本身并不是很有用。
另一方面，在 UML 中，您正试图捕获有关对象如何相互关联的所有此类信息。因此，重点是赋予术语更精确的含义。因此，当您在 UML 中调用组合时，您会想到一个非常具体的 has-a 关系，其中容器负责所包含项的生命周期。
UML 关联的实现
所有这些额外的概念信息意味着实际上没有精确的方法来实现关联。这是有道理的，因为实现将取决于目标编程语言或环境（例如，可执行模型，其中 UML 概念用作最终产品）。
作为示例，我可以推荐一篇描述 Java 中 UML 关联实现的论文，其中包含诸如多重性、导航性和可见性等强制概念 Implementing UML Associations in Java。
更多子问题
How I can say (and know) which composition are we talking about?
根据上下文，或者你可以直接问（不确定时这样做总是一件好事）。就我个人而言，只有在区别于继承时，我才听说将组合用作“有关系”；其余的则使用 UML。不过话说回来，我在学术界，所以我的观点有偏见。
Where we draw the line between the two definitions (in contextual terms)?
由于“编程”一词的组合实际上没有任何意义（只是它有一个），我建议您自己划清界线并敦促其他人使用更精确的术语。
Can I say that the first is object oriented programming and the second is software engineering/modeling?
或多或少，包含此答案中提到的所有细微差别。
Is the UML composition a model-only concept/jargon?
Is the UML composition an UML exclusive thing? or is also applied in the programming field?
不，您可以在编程中使用它来表示与在 UML 中相同的含义，但您可能需要更清楚地说明它。例如。 “这个 class 是那些 classes 的组合，因为它管理它们的生命周期。”。
重点是教人们区分常规的旧有关系和具有更精确语义的关系。
How to avoid miscommunication of "what composition are we talking about" in a team?
这是一个非常宽泛的问题，您可以将其应用于您想要附加特殊含义的任何术语（甚至软件工程是什么？），并且没有最佳方法。拥有团队共享的词汇表（您的领域中可能已经有很多特定术语），并引导人们使用更精确的术语。
编号引号指的是 UML 2.5 Specifications.
中的部分
Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship.
Deitel P.J., Deitel H.M。 - Java 如何编程第 9 版。
本主题讨论了这个观点： Prefer composition over inheritance?
Composition: Composite aggregation (composition) is a "strong" form of aggregation with the following characteristics:
*it is binary association,
*it is a whole/part relationship,
*a part could be included in at most one composite (whole) at a time, and
*if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it.
发现于 http://www.uml-diagrams.org/composition.html （实际上，Deitel 在同一本书中介绍了遵循这个想法的 UML 示例，但没有费心去解释不同之处）。
这个话题讨论了这个观点：
What is the difference between association, aggregation and composition?
很好，两者都是正确的。而这就引入了同音异义概念的问题。
例如：不要画一个带有复合箭头的UML模型来举例说明第一个定义：在UML中，任何关联都是由Deitels'第一个定义组成的。
以下是我的问题的一些方面，可能有助于正确回答：
我怎么能说（并知道）我们在谈论哪种作文？
我们在哪里划清两个定义之间的界限（在上下文中）？
我能说第一个是面向对象编程，第二个是软件吗engineering/modeling？
UML 组合是否只有模型concept/jargon？
UML组合是不是UML独有的东西？或者也应用在编程领域？
如何避免团队中“我们在谈论什么组成”的误解？
请回答参考文献和证据，这不是 philosophical/opinion 问题，这是我试图解决的“范围”问题。
而且这不是“什么是组合”的问题。
编辑：我在想区别是动词 x 形容词：“构成”class（第一个定义）和“复合关系”（第二个定义）。
引用第 110 页的 UML 2.5 规范：
Sometimes a Property is used to model circumstances in which one instance is used to group together a set of instances; this is called aggregation. To represent such circumstances, a Property has an aggregation property, of type AggregationKind; the instance representing the whole group is classified by the owner of the Property, and the instances representing the grouped individuals are classified by the type of the Property. AggregationKind is an enumeration with the following literal values:
none: Indicates that the Property has no aggregation semantics.
shared: Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
composite: Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects (see the definition of parts in 11.2.3).
我个人认为复合聚合的概念是关于对象生命周期的，而不是关于静态关系的。 复合聚合 会在其父项死亡时杀死聚合成员。 None 保持打开状态。 共享聚合 是 OMG 根本不应该引入的混蛋，因为它的语义是域相关的。
我发现很难解释 UML 关联和实现引用之间的区别，而不至少解释一下 UML 关联实际上是什么，以及它们可以做什么，所以我们开始吧。
协会 & Link
让我们先看看 UML 关联和 link（关联的实例）是什么。
[11.5.3.1] An Association specifies a semantic relationship that can occur between typed instances.
[11.8.1.1] A link is a tuple of values that refer to typed objects. An Association classifies a set of links, each of which is an instance of the Association. Each value in the link refers to an instance of the type of the corresponding end of the Association.
所以下面是有限关联的有效实现。
class Brain { }
class Head { }
a = new Brain;
b = new Head;
link = (new Array).add(a).add(b);
所有权
[9.5.3] When a Property is owned by a Classifier other than an Association via ownedAttribute, then it represents an attribute of the Classifier.
（注意：Class 是 Class 化器的子class。）
适航性
[11.5.3.1] An end Property of an Association that is owned by an end Class or that is a navigableOwnedEnd of the Association indicates that the Association is navigable from the opposite ends; otherwise, the Association is not navigable from the opposite ends. Navigability means that instances participating in links at runtime (instances of an Association) can be accessed efficiently from instances at the other ends of the Association. The precise mechanism by which such efficient access is achieved is implementation specific. If an end is not navigable, access from the other ends may or may not be possible, and if it is, it might not be efficient.
为什么这些概念相关？想象一下下面的例子。
我们看到 brain 是 Head class 的属性（黑点表示对面 Class 的所有权），并且它是可导航的（箭）。
我们还看到 head 不是 Brain 的属性（没有黑点 ⇒ 不属于 Brain class ⇒ 不是 Brain 的属性），但是它仍然可以导航。这意味着在 UML 中 head 属性 由关联本身持有。
例如，实现可能看起来像这样（关联本身由两个引用的元组表示（请参阅前面的 link 描述））。
class Head {
public Brain brain;
}
class Brain {
}
h = new Head;
b = new Brain;
h.brain = b;
link = (new Array).add(h).add(b);
因此，正如您希望开始看到的那样，UML 关联并不是像 has-a 关系这样简单的概念。
作文
让我们再添加一块，合成。
[11.5.3.1] A binary Association may represent a composite aggregation (i.e., a whole/part relationship). Composition is represented by the isComposite attribute [9.9.17] The value of isComposite is true only if aggregation is composite.
随着聚合
- none - Indicates that the Property has no aggregation semantics.
- shared - Indicates that the Property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeler.
- composite -- Indicates that the Property is aggregated compositely, i.e., the composite object has responsibility for the existence and storage of the composed objects
我们再次看到，UML 关联明确指定了难以从实现中感知的概念（例如，谁负责对象 management/destruction）。
模型组合与对象实现组合
因此，根据上面的描述，我们可以更准确地描述什么是实现组合（具有关系）。
[Deteils] Composition: A class can have references to objects of other classes as members. This is called composition and is sometimes referred to as a has-a relationship. McConnell [Code Complete 2, 6.3] also refers to has-a relationship as a Containment.
但是他们都没有谈论如何对象（容器包含的，作曲家复合的）彼此相关，谁负责生命周期，或者包含的元素是否了解容器。
所以只要说对象有一种关系（并称之为组合），你实际上可以指这些中的任何一个（以及更多）
因此，如果您在编程中称某些东西为组合，您几乎可以指任何 relationship/reference（或者更确切地说不是继承），所以这个词本身并不是很有用。
另一方面，在 UML 中，您正试图捕获有关对象如何相互关联的所有此类信息。因此，重点是赋予术语更精确的含义。因此，当您在 UML 中调用组合时，您会想到一个非常具体的 has-a 关系，其中容器负责所包含项的生命周期。
UML 关联的实现
所有这些额外的概念信息意味着实际上没有精确的方法来实现关联。这是有道理的，因为实现将取决于目标编程语言或环境（例如，可执行模型，其中 UML 概念用作最终产品）。
作为示例，我可以推荐一篇描述 Java 中 UML 关联实现的论文，其中包含诸如多重性、导航性和可见性等强制概念 Implementing UML Associations in Java。
更多子问题
How I can say (and know) which composition are we talking about?
根据上下文，或者你可以直接问（不确定时这样做总是一件好事）。就我个人而言，只有在区别于继承时，我才听说将组合用作“有关系”；其余的则使用 UML。不过话说回来，我在学术界，所以我的观点有偏见。
Where we draw the line between the two definitions (in contextual terms)?
由于“编程”一词的组合实际上没有任何意义（只是它有一个），我建议您自己划清界线并敦促其他人使用更精确的术语。
Can I say that the first is object oriented programming and the second is software engineering/modeling?
或多或少，包含此答案中提到的所有细微差别。
Is the UML composition a model-only concept/jargon? Is the UML composition an UML exclusive thing? or is also applied in the programming field?
不，您可以在编程中使用它来表示与在 UML 中相同的含义，但您可能需要更清楚地说明它。例如。 “这个 class 是那些 classes 的组合，因为它管理它们的生命周期。”。 重点是教人们区分常规的旧有关系和具有更精确语义的关系。
How to avoid miscommunication of "what composition are we talking about" in a team?
这是一个非常宽泛的问题，您可以将其应用于您想要附加特殊含义的任何术语（甚至软件工程是什么？），并且没有最佳方法。拥有团队共享的词汇表（您的领域中可能已经有很多特定术语），并引导人们使用更精确的术语。
编号引号指的是 UML 2.5 Specifications.
中的部分