为什么在命令模式中没有从客户端到接收者和调用者的依赖箭头？答案

【问题标题】：Why are there no dependency arrows from the client to the receiver and invoker in the command-pattern?为什么在命令模式中没有从客户端到接收者和调用者的依赖箭头？
【发布时间】：2020-04-01 06:08:24
【问题描述】：

在 OOP 中，当类使用关键字 new 创建实例时，存在依赖关系。关于Wikipedia，UML 符号通过带有虚线的箭头显示依赖关系：

网站https://www.dofactory.com/net/command-design-pattern 显示了命令模式的代码及其UML。这个网站上的代码有一个客户端类（我认为是MainApp），其中包含三倍关键字new，用于为接收者、命令和调用者创建一个实例。

// Client
class MainApp
{
    /// <summary> 
    /// Entry point into console application.
    /// </summary>
    static void Main()
    {
        // Create receiver, command, and invoker
        Receiver receiver = new Receiver(); // <- no dashed arrow in UML
        Command command = new ConcreteCommand(receiver); // <- dashed arrow in UML
        Invoker invoker = new Invoker(); // <- no dashed arrow in UML

        // [...]
    }
}

abstract class Command
{
    // [...]
}

class ConcreteCommand : Command
{
    public ConcreteCommand(Receiver receiver) : base(receiver)
    {
        // [...]
    }

    // [...]
}

class Receiver
{
    // [...]
}

class Invoker
{
    // [...]
}

你可以在这里找到完整的代码：https://www.dofactory.com/net/command-design-pattern

为什么这个website 上的UML 只显示客户端对具体command 的依赖关系？因为客户端也在接收者和调用者上使用了关键字new。我还期望 UML 中的接收者和调用者的依赖关系箭头。

【问题讨论】：

是的，代码属于图表。见这里：dofactory.com/net/command-design-pattern
@qwerty_so：我现在从 dofactory.com/net/command-design-pattern 中添加了主要代码 sn-ps
您是否因为使用工具创建图表而抱怨？
如果是这样，请在此处查看我的答案：stackoverflow.com/questions/60861006/…
@qwerty_so：对不起，我说得不准确。问题是，为什么网站dofactory.com/net/command-design-pattern（我在其中复制了 UML）和其他来源显示没有依赖关系的 UML。

标签： c# design-patterns uml

【解决方案1】：

这可能只是一个简单的示例，在现实世界中，您应该获得由 DI 容器注入的调用者和接收者。但是命令总是通过调用代码来指定（你的代码无论如何都知道具体的具体命令）

【讨论】：

我喜欢你的回答。感谢您的耐心等待。

【解决方案2】：

从设计模式的角度来看，Command 对象如何从创建它的 Client 到执行它的 Invoker 并不重要。如果Client 直接将其传递给Invoker（因此具有直接依赖关系），那很好。如果Client 将Command 持久化到数据库中并且Invoker 稍后检索它，那也可以。

从 UML 的角度来看，Client 和 Invoker 之间没有界限，因为没有必要。添加该行可能意味着需要依赖。

从代码示例的角度来看，在一个主类中实例化所有内容既简单又直接，因此您可以理解为什么您会在众多教程中看到它以这种方式实现。请记住，您可能会看到在现实世界中实现的模式有所不同，并且仍然遵循 UML。

【讨论】：

不是设计模式的问题，而是后者的应用问题。但也许这正是造成这里混乱的原因。
UML 源自 GoF 设计模式书，因此我将其解释为模式问题。值得注意的是，自从这本书于 1994 年出版以来，它早于 UML 规范。但由于我们质疑没有线路，所以日期并不重要。最终，答案是缺失的链接是设计使然，而不是意外遗漏。

【解决方案3】：

总有一个用户或客户在你的代码中使用你的模式。像 DI 这样的一些技术使用另一种方法来创建您的对象并将其放入 ram 中并将其注入您的代码中。

出于这个原因，并且为了简化所有显示 Gof 模式的 UML，显示了在您的代码中使用“新关键字”来生成对象的客户端。

所以它只是使用 New 关键字来向我们展示在客户端中的使用。在现实世界中，我们使用 DI 将我们的依赖注入到类中。

您还可以看到另一个有价值的参考：

Command Pattern

【讨论】：