实际业务逻辑在Command模式中属于哪里？在互联网上

例子，像例如here，弄得我关于Command模式在大多数例子中具体的命令直接调用的接收器的方法之一。这是具体命令的唯一责任吗？实际的业务逻辑属于哪里？在具体命令的方法中还是在接收方的某种方法中？实际业务逻辑在Command模式中属于哪里？在互联网上

另一个问题是，如果我们想要实现多线程命令模式，我们的线程池应该接收来自Invoker的命令并运行具体命令的方法？我的理解是否正确？

来源

2015-05-09 Majid Azimi

命令的执行必须触发接收器。无论您是直接在接收器内写入业务逻辑，还是从接收器内将其委托给另一个类，都是您必须作出的选择。这就是说，你在一个问题中问了两个不相关的问题。理想情况下，您的第二个问题应作为另一个问题发布，以增加获得答案的机会。另外，我也完全不理解你的第二个问题。你能否详细说明一下？ – CKing

要么是可能的，我已经实现了指挥与包含在简单的应用程序命令的执行具体命令，但是，在典型的大型应用程序，命令需要做的无非就是传达命令和任何参数的类型。由接收者来决定是否包含或委托实现该行为。

这是因为客户端必须依赖于具体的命令。如果具体命令又需要复杂的依赖性来实现行为，那么客户端间接依赖于那些复杂的依赖关系，这会导致系统不稳定。相反，具体的命令应该没有复杂的依赖关系，这样客户端就可以毫不畏惧地依赖它们。

[我忽略了你的第二个问题。请将其移到一个新的问题，所以我们可以单独回答。]

来源

2016-02-14 04:33:58

业务逻辑在于接收机（大多数逻辑）和的ConcreteCommand（一些逻辑）班。

客户调用祈求 =>祈求调用的ConcreteCommand =>的ConcreteCommand呼叫接收机方法，它实现抽象命令方法。

优势：客户不会受到影响的命令和接收器的变化。 Invoker在客户端和Receiver之间提供松耦合。您可以使用相同的Invoker运行多个命令。

你的理解是对线程前正确的。你可以把的Runnable的或赎回为混凝土命令/接收器的ExecutorService为祈求和Runnable接口或赎回为抽象的命令和实现类。我看到ConcreteCommand本身扮演着的角色接收器在简单的多线程应用程序。

看一看这个问题，以便更好地理解：

Using Command Design pattern

来源

2016-02-14 04:46:39

实际业务逻辑在Command模式中属于哪里？在互联网上

回答

相关问题