设计模式：哪个 UML 关系最好地描述了这个类？答案

【问题标题】：Design pattern: Which UML relationship best describes this class?设计模式：哪个 UML 关系最好地描述了这个类？
【发布时间】：2016-08-03 05:55:24
【问题描述】：

给定以下类：

public class CardGame extends Game {
    private CardDeck[] cardDecks;
    public CardGame(int numCardDecks) {
        super();
        cardDecks = new CardDeck[numCardDecks];
        for (int i=0; i < numCardDecks; i ++) {
            cardDecks[i] = new CardDeck();
        }
    }
}

哪个 UML 关系最能描述这个类？（为什么？）
- 聚合 - 作品 - 概括 - 工厂

注意：我认为这个单选题本身并没有明确定义。

【问题讨论】：

你能解释一下你为什么想知道这个吗？聚合和组合向模型添加的语义非常少，而且仅在少数情况下。
@YuChen，这看起来像是作业。你认为答案是什么？为什么？
@jaco0646 非常接近，实际上是 Java 专业证书的商业模拟测试中的一个问题。我在争论这个答案，泛化，并发现自己与这里的其他专业一致。没有什么真正复杂的反馈，我相信已经提交了其他几个错误答案的问题。
@jaco0646 不是家庭作业，而是来自编码/证书模拟考试。到目前为止，我同意这里的答案，它们得到了很好的解释。

标签： design-patterns uml notation

【解决方案1】：

聚合、组合和泛化是 UML（类图）符号，代表不同类型的关系，即逻辑连接的类型。

在您的情况下，“游戏”是“纸牌游戏”的概括； 'CardGame 是'Game' 的特化。我想说的是，在您的情况下，“CardDecks”与您的“Cardgame”具有组合关系，因为您的卡是在“CardGame”类中创建的，如果您删除“CardGame”，则会被删除，即“暗示一种关系孩子不能独立于父母而存在”（What is the difference between aggregation, composition and dependency?）。但是，如果您将特定的“CardDecks”存储在数据库中，或者如果您尝试对可以在另一个游戏中使用卡片的真实世界进行建模，那么它就是聚合。您的 CardDeck 类是一个“工厂方法”，因为它是一个创建对象的类。

我认为这不应该归类为设计模式，因为要成为一种设计模式，它就必须描述软件设计中常见问题的重复解决方案。

“在软件工程中，设计模式是针对软件设计中常见问题的通用可重复解决方案。设计模式不是可以直接转换为代码的完成设计。它是关于如何实现的描述或模板解决可以在许多不同情况下使用的问题。” (https://sourcemaking.com/design_patterns)

【讨论】：

精通，同意。

【解决方案2】：

Game 将CardGame 泛化为CardGame 派生自它。

我认为cardDecks 是CardDeck 的组合，因为CardGame 控制它们的生命周期，并且在这段代码的上下文中，它们只能属于CardGame。

【讨论】：

嗯...你想说Game是CardGame的泛化，不是吗？注意，空三角形箭头应该指向游戏块。
当然。也许正确的语言是'Gamegeneralises CardGame'？
箭头称为“泛化”。所以，当然，您的变体更具可读性和可理解性，但提问者试图理解 UML 俚语......所以，这两种变体都可以由我决定。现在你的答案是正确的、简短的和完整的——理想的变体。