类规范，替代继承？答案

【问题标题】：Class specification, alternative to inheritance?类规范，替代继承？
【发布时间】：2015-07-15 15:53:29
【问题描述】：

我需要您的意见和建议，以使我的课程达到最佳规格。一个领导者有一个人员团队，每个人都可以成为许多领导者团队的一部分。领导者不能是任何其他团队的成员。

哪种解决方案会更好？如果您有其他选择，我将不胜感激，（我正在使用 JPA 开发 JAVA 应用程序）

UML 图：

非常感谢

编辑：我想我会用这个例子更好地解释我的问题，但实际上我不这么认为，这是原始问题： UML specification : Do I need inheritance?

【问题讨论】：

一个人可以领导多个团队吗？您是否跟踪 Teams 中过去和未来的成员资格？一个人可以将领导责任交给其他人并加入团队吗？团队是否有身份、名称或任何其他属性？你知道每个列表都在复制一个关联端吗？
一个人只能领导一个团队，是的，可以跟踪过去和未来在 Teams 中的成员身份，Leader 始终是领导者，不能加入团队，团队没有绝对的礼仪，非常感谢。

【解决方案1】：

大多数团队都有一个您无法在模型中捕捉到的身份。现在可能没有这个要求，但如果明天有呢？建模现实往往会使模型更耐用，因为当需求变得更清晰或发生变化时，您不必完全重做模型。出于这个原因，我建议您让模型更像现实世界。

话虽如此，我认为您可能遗漏了一些东西：

另外，使用关联端名称。假设您使用的是真正的 UML 工具，您的模型已经包含已表示列表的未命名属性，那么为什么不命名并使用它们而不是复制它们呢？

【讨论】：

非常感谢您的回答，但是对于我的申请，团队绝对有任何属性，我以后不会使用它（这就是为什么我没有在我的图表中指定它)
忽略问题领域中如此突出的内容是很奇怪的。这是一个玩具例子吗？您的软件为用户做了什么？
是的，这是一个玩具示例（实际上我认为这是我制作的一个坏示例），我认为它可以更好地解释我的问题：这是真正的问题：stackoverflow.com/questions/31458978/… 非常感谢

【解决方案2】：

我会想出以下内容：

（从Composition 派生的最后两个要点没有多重性）

正如您所见，UML 的表达方式非常简单。

【讨论】：

对角色使用子类化可能很危险。如果需求发生变化并且人也必须能够扮演其他角色怎么办？这让我想起了克林顿的话。这取决于“是”的定义是什么。 ?
@JimL。我想这里的答案都不是完美的。但是他们中的很多人让你的头脑朝着另一个有用的方向前进:-)
恐怕我不明白你的评论。
我的意思是我没有在我的 UML 图中指定 Team 类，因为在我的应用程序中，一个团队没有任何属性（没有名称，没有属性）并且我不会使用它在我的应用程序中。不使用 Team 类就没有别的选择了吗？
好吧，您可以将属性放入Person 和Leader 并应用约束。但是Team 类（除了关联类的属性外没有其他属性）显然简化了整个事情。