如何解决命令处理程序在命令模式中方法过多的问题
我们计划在流程管理项目中应用命令模式：
- 要实现的
Command接口 - 一个
CommandProcessor，它真正地执行一些任务
CommandProcessor通过构造函数传递给Command实例，以便Command中的execute()方法最终在CommandProcessor中触发真正的执行。
所以CommandProcessor的代码如下所示：
public class CommandProcessor {
public doWork1() {
//implementation
}
public doWork2() {
//implementation
}
public doWork3() {
//implementation
}
...
public doWork200() {
//implementation
}
}正如代码片段所指出的，在我们的用例中，命令模式的下降是，可能有数百条命令，因此在长期中可能很难维护。因此，如何解决此缺陷
回答 1
Stack Overflow用户
发布于 2019-01-03 09:25:39
对我来说，这不像是命令模式。您突出显示的设计不会向调用方隐藏实现细节。它将调用该方法的所有逻辑都放在调用方的后面，而不是隐藏在接口后面。
命令模式的主要原因是命令的调用者根本不需要知道命令是什么，它做什么，所有这些都封装在命令本身中。
我觉得你对200种指挥方法的恐惧是有道理的。首先，考虑一下在添加、删除或更改这些工作方法的含义时会发生什么。不仅需要更改接口，还需要实现该接口的所有具体类，以及调用接口的所有位置。
通常，命令模式有一个执行接口，有关模式的描述，请参阅本文
正如@robert在您的评论中提到的，我认为您应该重新考虑您的API。
编辑
在与“瑞”进行了一次愉快的交谈后，我最好能理解这个问题，并有以下几点话要说。
虽然我误解了最初的问题，但我仍然准备坚持这样的说法，即需要重新设计。当命令模式被遵循的时候，我不认为这个模式的精神是。传递给命令( commandProcessor)的对象是命令操作的接收方，但这看起来不像是一个合适的对象。显然，我缺少上下文，但对于我来说，任何以-er结尾的对象都会引发大标志，因为它不是真正的对象，而是对某人执行数据操作的方法的集合。
这里是一个很好的小文章，有一些链接。我经常发现，像管理器、处理器或助手这样的类与贫血域模型是紧密相连的。也许您正处于正确轨道的开始，我将要求您查看这个commandProcessor，看看它是否实际上是许多可以封装自己的数据和方法的排减对象。
https://stackoverflow.com/questions/54009165
复制相似问题
腾讯云开发者
