我刚开始学习设计模式，一种是命令模式。在阅读了一些资料和一些文档后，例如
http://www.oodesign.com/command-pattern.html https://www.tutorialspoint.com/design_pattern/command_pattern.htm
我想到了使用命令模式进行股票买卖。客户可以先决定他/她想出售或购买哪只股票，然后让代理/经纪人调用命令的执行功能。我认为这是有道理的。
另外一个“经典”的例子是餐厅，这让我很困惑。作为客户，客户如何知道哪个厨师（接收者）能够烹制该物品（示例中的汤或烤架）？我认为厨师不应由客户决定。谁能指出我应该如何处理这个想法？
谢谢！
【问题讨论】：
标签： oop design-patterns command-pattern
我相信您没有正确考虑餐厅示例。顾客不直接给厨师点菜，女服务员把菜送到厨房，然后排队，厨师可以在有空时点菜。
在代码中，这看起来像是女服务员添加到的共享队列，厨师处于连续循环中，他们在其中烹饪食物，然后接受他们能够烹饪的下一个订单。此示例中的命令模式只是从客户转移到厨房的订单。
【讨论】：
实际上，您的问题超出了命令模式实际试图解决的问题范围。
如果您熟悉 Java，您可以很容易地从 Java 线程中了解Command 模式。实际上 Thread.run()（不仅是 run()）简而言之就是命令模式。
主要思想是，如果我们有一组具有重要功能的对象（扩展 Command 接口的具体 Command 对象），则使用不具有任何方法参数或类型的固定方法来实现它。因此，任何想要执行该功能的调用者（CommandHandler）都可以在不知道具体类是什么的情况下实际执行该功能。它可以执行someCommandObject.execute();。唯一的要求是必须是 Command 接口的实例。
在 Java 线程示例中，让我们考虑一下 JVM/操作系统。您知道任何程序都作为线程进入该级别，正在执行的程序作为该线程的进程驻留。这样线程执行器就可以通过anyThread.start()、anyThread.sleep()等执行任意线程进程。
在餐厅示例中，实际的命令对象是SoupOrder、GrillOrder 等。CommandHandler 是Waiter。考虑一种情况，我们引入另一个名为LunchOrder 的命令对象，它是Command 类的子对象，并实现void execute(){}。现在您不必对调用程序 (Waiter) 进行任何更改，因为它仍然可以调用 lunchOrder.execute()。所以发布者（命令对象）和客户端（调用者）实现是分离的。这就是命令模式的美妙之处。
您也可以参考this。 :))
【讨论】：