这两种设计模式都封装了一个算法，并将实现细节与其调用类分离。我能看出的唯一区别是 Strategy 模式接受参数来执行，而 Command 模式没有。
在我看来，命令模式要求所有执行信息在创建时都可用，并且能够延迟调用（可能作为脚本的一部分）。
什么决定指导是使用一种模式还是另一种模式？
【问题讨论】：
标签： design-patterns encapsulation strategy-pattern command-pattern
我包含了几个 GoF 设计模式的封装层次表，以帮助解释这两种模式之间的差异。希望它能更好地说明每个封装的内容，以便我的解释更有意义。
首先，层次结构列出了给定模式适用的范围，或用于封装某种详细程度的适当模式，具体取决于您从表格的哪一侧开始。
从表中可以看出，策略模式对象隐藏了算法实现的细节，因此使用不同的策略对象将执行相同的功能，但方式不同。每个策略对象都可能针对特定因素进行优化或对其他参数进行操作；并且，通过使用通用接口，上下文可以安全地使用其中任何一个。
与算法相比，命令模式封装的详细程度要小得多。它对向对象发送消息所需的细节进行编码：接收器、选择器和参数。将流程执行的这么小部分客观化的好处是，可以在不同的时间点或位置以一般方式调用此类消息，而无需对其细节进行硬编码。它允许消息被调用一次或多次，或者传递到系统的不同部分或多个系统，而不需要在执行之前知道特定调用的细节。
作为典型的设计模式，它们并不要求所有实现在细节上都相同以使用模式名称。实现细节以及在对象中编码的数据与作为方法参数的数据可能有所不同。
【讨论】：
策略封装了算法。命令将请求的发送者与接收者分开，它们将请求转换为对象。
如果是算法，如何做某事，请使用策略。如果您需要将方法的调用与其执行分开，请使用命令。当您将消息排队以备后用时，通常会使用命令，例如任务或事务。
【讨论】：
回答一个非常古老的问题。 （有人看到最新的答案而不是投票最多的答案吗？）
由于相似之处，这是一个有效的混淆。策略和命令模式都使用封装。但这并不能使它们相同。
关键的区别在于理解什么被封装了。两种模式所依赖的 OO 原则是封装变化的内容。
就策略而言，变化的是算法。例如，一个策略对象知道如何输出到 XML 文件，而另一个输出到例如 JSON。不同的算法被保存（封装）在不同的类中。就这么简单。
在命令的情况下，变化的是请求本身。请求可能来自File Menu > Delete 或Right Click > Context Menu > Delete 或Just Delete Button pressed。这三种情况都可以生成 3 个相同类型的命令对象。这些命令对象仅代表 3 个删除请求；不是删除算法。由于请求现在是一堆对象，我们可以轻松地管理它们。突然之间，提供撤消或重做等功能变得微不足道。
命令如何实现请求的逻辑并不重要。在调用 execute() 时，它可以实现一个算法来触发删除，或者它甚至可以将其委托给其他对象，甚至可以委托给一个策略。它只是命令模式的实现细节。这就是为什么它被命名为 command 虽然它不是一种礼貌的方式 request :--)
将其与策略进行对比；这个模式只关心被执行的实际逻辑。如果我们这样做，它有助于以最少的类集实现不同的行为组合，从而防止类爆炸。
我认为，Command 帮助我们拓宽了对封装的理解，而 Strategy 则提供了对封装和多态性的自然使用。
【讨论】：
我的看法是，你有多种方式来做同样的事情，每一种都是一个策略，运行时的某些东西决定了哪个策略会被执行。
不妨先试试 StrategyOne，如果效果不够好，试试 StrategyTwo...
命令绑定到需要发生的不同事情，例如 TryToWalkAcrossTheRoomCommand。每当某个对象试图穿过房间时，都会触发此命令，但在其中，它可能会尝试使用 StrategyOne 和 StrategyTwo 来尝试穿过房间。
标记
【讨论】：
我的观点可能是错误的，但我将command 视为执行功能或反应。至少应该有两个玩家：一个请求动作，一个执行动作。 GUI 是命令模式的典型示例：
该命令通常限于某个范围或业务领域，但不是必需的：您可能有一些命令可以在一个应用程序中发出账单、启动火箭或删除实现相同接口（例如单个execute() 方法）的文件.通常命令是自包含的，因此它们不需要执行器的任何东西来处理它们打算执行的任务（所有必要的信息都在构造时给出），有时命令是上下文敏感的，应该能够发现这个上下文（Backspace 命令应该知道文本中插入符号的位置以正确删除前一个字符；Rollback 命令应该发现当前事务以回滚；...）。
strategy 有点不同：它更多地绑定到某个区域。该策略可以定义一个规则来格式化日期（在 UTC？特定于区域设置？）（“日期格式化程序”策略）或计算几何图形的正方形（“正方形计算器”策略）。从这个意义上说，策略是轻量级对象，它将某些东西作为输入（“日期”、“图形”……）并在其基础上做出一些决定。也许不是最好的，但是一个很好的策略示例是与javax.xml.transform.Source 接口连接的策略：取决于传递的对象是DOMSource 或SAXSource 还是StreamSource，策略（在这种情况下为XSLT 转换器）将应用不同的处理它的规则。实现可以是简单的switch，也可以涉及Chain of responsibility pattern。
但这两种模式确实有一些共同点：命令和策略将算法封装在同一个语义区域内。
【讨论】：
命令：
基本组件：
execute()
工作流程：
Client 调用 Invoker => Invoker 调用 ConcreteCommand => ConcreteCommand 调用Receiver方法，实现抽象的Command方法。
优势：客户端不影响命令和接收器的更改。 Invoker 提供 Client 和 Receiver 之间的松散耦合。您可以使用同一个 Invoker 运行多个命令。
Command 模式允许您使用相同的Invoker 在不同的Receiver 上执行命令。 Invoker 不知道 Receiver
的类型为了更好地理解概念，除了维基百科链接之外，请查看 Pankaj Kumar 的 JournalDev article 和 James Sugrue 的 dzone article。
你可以使用Command模式来
解耦调用者和命令接收者
实现回调机制
实现撤消和重做功能
维护命令历史记录
java.lang.Thread 是 Command 模式的一个很好的实现。您可以将 Thread 视为调用者和实现 Runnable 的类作为 ConcreteCommonad/Receiver 和 run() 方法作为 Command。
命令模式的撤消/重做版本可以在 Theodore Norvell'sarticle
阅读策略：
策略模式很容易理解。当
一个算法有多个实现，算法的实现可以根据特定条件在运行时改变。
以航空公司预订系统的票价组件为例
航空公司希望在不同的时间段（高峰期和非高峰期）提供不同的票价。在非高峰旅行期间，它希望通过提供有吸引力的折扣来刺激需求。
策略模式的关键要点：
带有代码示例的相关帖子：
【讨论】：
对我来说，区别在于意图之一。这两种模式的实现非常相似，但用途不同：
对于策略，使用对象的组件知道 对象做了什么（并将使用它来执行自己的部分工作），但它并不关心 如何做到这一点。
对于命令，使用对象的组件既不知道命令做什么，也不知道如何执行它——它只知道如何调用它。调用者的任务只是运行命令——命令执行的处理不构成调用者核心工作的一部分。
这就是区别——使用组件的对象是否真的知道或关心组件的功能？大多数情况下，这可以根据模式对象是否向其调用者返回值来确定。如果调用者关心模式对象的作用，那么它可能希望它返回一些东西，这将是一个策略。如果它不关心任何返回值，它可能是一个命令（注意，像 Java Callable 之类的东西仍然是一个命令，因为尽管它返回一个值，但调用者并不关心该值 - 它只是将它传回到最初提供命令的任何东西）。
【讨论】：