本问题已经有最佳答案,请猛点这里访问。
我在完全了解组成和聚合时遇到了一些麻烦。 根据我的理解,构图关系意味着一个人死亡,另一个人死亡。 聚合意味着它们是由它们构成的,但不一定依赖于事物是否继续存在。
这是我拼凑起来的UML。 我是否正确理解了这个概念?
我会告诉你,你的Card类看起来不对。 这些整数属性应该完成什么?
@JimL。 Haha im正在使用预定义的Card类。 我不会以这种方式设计它,但是必须解决这个设计问题。
您使用什么工具绘制此图,为什么为什么要在几个类中重复两次memberName? 看起来不像真正的UML。
我用过visio,而且它不完整。 我还没有定义变量和方法。 我只是想更好地理解聚合/组成类型。
什么是组成和聚合?
组成和聚集表示整体/部分关系(UML 2.5,第11.5.3.1节):
A binary Association may represent a composite aggregation (i.e., a
whole/part relationship).
因此,如果您使用菱形,则在考虑如何创建或删除对象之前,首先应问一下它是否真的是整体/零件关系。
然后,合成对共享聚合具有其他约束。在组成关系中(UML 2.5,第9.5.3节):
(...) the composite object has responsibility for the existence and storage
of the composed objects.
Composite aggregation is a strong form of
aggregation that requires a part object be included in at most one
composite object at a time. If a composite object is deleted, all of
its part instances that are objects are deleted with it.
分析您的特定图表
根据您的图表:
玩家仅存在于一个游戏中(即临时标识不存在于多个游戏中)。组成可能是有意义的,因为可以将玩家视为游戏的一部分。
这只手仅与玩家有关。那讲得通。但这真的是一种构成关系吗?手是玩家的一部分吗?玩家是由手组成的吗?玩家不会按顺序但不同时有几手牌吗?我真的对这里的构图感到怀疑;我会用一名普通的多手牌玩家代表这一点。
游戏汇总了几个套牌。我不知道您的比赛,但我希望能有一个套牌。如果使用了多个套牌,并且套牌仅存在于游戏中(类似于玩家),我宁愿看到一个合成而不是一个集合。另外,您可能不是说套牌,而是套牌及其状态。在这种情况下,我会选择一对多关联而不是合成(套牌+状态不会成为您游戏的组成部分,而是定义游戏状态)。
牌组是独立于牌组而存在的牌的集合。这让我很烦恼,因为我的世界经验一直表明,卡片是卡组的一部分。如果我在某处找到孤立的卡片,我总会寻找它的副牌。因此,我宁愿期望卡片和卡片组之间有一个组合。
最后,一手牌是几张牌的集合,这似乎是有道理的。请注意,这与卡座和卡之间的构图不兼容。
谢谢。 这帮助了很多。
您对UML 2.5的引用不完整。 它们还令人困惑地说:"零件对象可能在删除组合对象之前从组合对象中删除,因此不能作为组合对象的一部分被删除"。 看到我的答案stackoverflow.com/questions/734891/