Question

我们计划在我们的流程管理项目中应用命令模式：有

要实施的Command接口
一个CommandProcessor，可以真正执行某些任务

CommandProcessor通过 constructor 传递给Command实例，以便execute()中的Command方法最终将触发真正的执行。 CommandProcessor

所以CommandProcessor的代码如下：

public class CommandProcessor {
    public doWork1() {
      //implementation
    }
    public doWork2() {
      //implementation
    }
    public doWork3() {
      //implementation
    }

    ...

    public doWork200() {
      //implementation
    }
}

如代码片段所示，在我们的用例中，命令模式的缺点为，可能有数百条命令，因此CommandProcessor长期而言可能很难维护。那么如何解决这个缺点？

Answer 1

这对我来说不像命令模式。您突出显示的设计不会向调用者隐藏实现细节。它将所有逻辑与调用方一起调用该方法，而不是将其隐藏在接口后面。

使用“命令”模式的主要原因是命令的调用者根本不需要了解命令的含义，功能，所有这些都封装在命令本身中。

我感到您担心拥有200种命令方法值得。首先考虑添加，删除或更改任何这些工作方法的签名时会发生什么。不仅需要更改接口，还需要更改实现该接口的所有具体类以及调用该接口的所有位置。

通常，命令模式具有一个执行界面，有关command_pattern的描述，请参见此维基百科文章

正如@robert在您的评论中所述，我认为您应该重新考虑您的API。

修改

与@Rui进行了良好的交谈后，我更好地理解了这个问题，并提出以下意见。

虽然我误解了最初的问题，但我仍然准备支持需要重新设计的声明。在遵循命令模式的同时，我不认为该模式的实质是。传递给命令的对象（commandProcessor）是命令操作的接收者，但这看起来不像是正确的对象。显然，我缺少上下文，但是对我来说，任何以-er结尾的对象都并非真正是对象而是大标志，而是作用于其他人数据的方法的集合。

Here很好地写了一些链接。我经常发现诸如管理者，处理者或帮助者之类的课程与Anemic Domain Model并驾齐驱。也许您处在正确的道路上，我会挑战您看一下commandProcessor，看看它实际上不是许多可以封装自己的数据和方法的离散对象。

如何在命令模式下解决命令处理器中方法过多的问题

1 个答案: