本文是小编为大家收集整理的关于使用策略模式和命令模式的处理/解决方法，可以参考本文帮助大家快速定位并解决问题，中文翻译不准确的可切换到English标签页查看源文。
问题描述
两种设计模式都封装了算法和将其呼叫类中的实现详细信息.我唯一可以看出的区别是，策略模式为执行参数带有参数，而命令模式则没有.
在我看来，命令模式需要所有在创建时可用的信息，并且能够延迟其调用(也许是脚本的一部分).
哪些确定指南是使用一种模式还是另一种模式?
推荐答案
我包括几种GOF设计模式的封装层次结构表，以帮助解释这两种模式之间的差异.希望它能更好地说明每个封装的内容，因此我的解释更有意义.
首先，层次结构列出了给定模式适用的范围，或用于封装某些细节的适当模式，具体取决于您从表的哪一侧.
您可以从表中看到，策略模式对象隐藏了算法实现的详细信息，因此使用其他策略对象的使用将执行相同的功能，但以不同的方式执行.每个策略对象都可以针对特定因素进行优化或在某些其他参数上操作；而且，通过使用通用界面，上下文可以安全地与两者一起使用.
命令模式封装了比算法要小得多的细节.它编码将消息发送到对象所需的详细信息:接收器，选择器和参数.客观化过程执行的一小部分的好处是，可以以一般的方式沿着不同的时间或位置调用此类消息，而无需对其进行详细编码.它允许将消息调用一次或多次，或传递到系统的不同部分或多个系统的不同部分，而无需在执行之前要知道特定调用的详细信息.
作为设计模式的典型特征，它们不需要所有实现都具有相同的详细信息来承担模式名称.详细信息的实现可能会有所不同，并且在对象中编码了哪些数据，而不是作为方法参数.
其他推荐答案
策略封装算法.命令将发件人与请求的接收器分开，他们将请求变成对象.
如果是算法，如何完成某件事，请使用策略.如果您需要将方法与执行方式分开，请使用命令.当您排队以供以后使用(例如任务或事务)时，通常会使用命令.
其他推荐答案
回答一个非常古老的问题. (有人看到最新答案而不是最投票吗?)
由于相似之处，这是有效的混乱.策略和命令模式都使用封装.但这并不能使它们相同.
关键区别是了解封装的内容.两种模式都取决于OO原理 封装了什么变化.
在制定策略的情况下，变化是算法.例如，一个策略对象知道如何输出到XML文件，而另一个策略对象则输出到JSON.在不同类别中保留不同的算法(封装).就像那样简单.
在命令的情况下，有什么变化是 request 本身.请求可能来自File Menu > Delete或Right Click > Context Menu > Delete或Just Delete Button pressed.所有三种情况都可以生成同一类型的3个命令对象.这些命令对象仅表示删除的3个请求；不是删除算法.由于现在的请求是一堆对象，因此我们可以轻松地管理它们.突然提供诸如撤消或重做之类的功能变得微不足道.
命令如何实现请求的逻辑无关紧要.在调用execute()时，它可以实现算法以触发删除，甚至可以将其委派给其他对象，甚至可以委派给策略.它只是命令模式的实现细节.这就是为什么它被称为命令，尽管它不是 request : - )
的礼貌方法与策略对比；此模式仅关注执行的实际逻辑.如果我们这样做，它有助于实现不同类别的行为组合，从而防止阶级爆炸.
我认为，命令有助于我们扩大对封装的理解，而战略则可以自然使用封装和多态性.
问题描述
Both design patterns encapsulate an algorithm and decouple implementation details from their calling classes. The only difference I can discern is that the Strategy pattern takes in parameters for execution, while the Command pattern doesn't.
It seems to me that the command pattern requires all information for execution to be available when it is created, and it is able to delay its calling (perhaps as part of a script).
What determinations guide whether to use one pattern or the other?
推荐答案
I'm including an encapsulation hierarchy table of several of the GoF design patterns to help explain the differences between these two patterns. Hopefully it better illustrates what each encapsulates so my explanation makes more sense.
First off, the hierarchy lists the scope for which a given pattern is applicable, or the appropriate pattern to use to encapsulate some level of detail, depending on which side of the table you start at.
As you can see from the table, a Strategy Pattern object hides details of an algorithm's implementation, so the use of a different strategy object will perform the same functionality but in a different way. Each strategy object might be optimized for a particular factor or operate on some other parameter; and, through the use of a common interface, the context can safely work with either.
The Command Pattern encapsulates a much smaller level of detail than an algorithm. It encodes the details needed to send a message to an object: receiver, selector and arguments. The benefit to objectifying such a tiny part of the process execution is that such messages can be invoked along different points of time or location in a general way without having to hard-code its details. It allows messages to be invoked one or more times, or passed along to different parts of the system or multiple systems without requiring the details of a specific invocation to be known before execution.
As is typical for design patterns, they do not require all implementations to be identical in detail to bear the pattern name. Details can vary in implementation and in what data is encoded in the object versus as method arguments.
其他推荐答案
Strategies encapsulate algorithms. Commands separate the sender from the receiver of a request, they turn a request into an object.
If it's an algorithm, how something will be done, use a Strategy. If you need to separate the call of a method from its execution use a Command. Commands are often used when you queue up messages for later use, like a task or a transaction.
其他推荐答案
Answering a very old question. (is anybody seeing lastest answers instead of most voted?)
It is a valid confusion to have because of the similarities. Both Strategy and Command patterns utilize encapsulation. But that does not make them same.
The key difference is to understand what is encapsulated. The OO principle, both patterns depend on, is Encapsulate what varies.
In case of strategy, what varies is algorithm. For example, one strategy object knows how to output to XML file, while the other outputs to, say, JSON. Different algorithms are kept (encapsulated) in different classes. It is as simple as that.
In case of command, what varies is the request itself. Request may come from File Menu > Delete or Right Click > Context Menu > Delete or Just Delete Button pressed. All three cases can generate 3 command objects of same type. These command objects only represent 3 requests for deletion; not deletion algorithm. Since requests are bunch of objects now, we could manage them easily. Suddenly it become trivial to provide functionality such as undo or redo.
It doesn't matter how command implements the requested logic. On calling execute(), it may implement an algorithm to trigger deletion or it can even delegate it to other objects, may even delegate to a strategy. It is only implementation detail of the command pattern. This is why it is named as command though it is not a polite way to request :--)
Contrast it with strategy; this pattern is only concerned with the actual logic that gets executed. If we do that, it helps to achieve different combinations of behaviors with minimal set of classes, thus preventing class explosion.
I think, Command helps us to broaden our understanding of encapsulation while Strategy provides natural use of encapsulation and polymorphism.
更多相关问答
联系站长