如何以简洁的方式对越来越多的带有参数的命令进行建模答案

【问题标题】：How to model an increasing amount of Commands with Parameters in a clean way如何以简洁的方式对越来越多的带有参数的命令进行建模
【发布时间】：2012-08-03 10:15:04
【问题描述】：

这是How to get rid of instanceof in this Builder implementation的后续帖子

这个设计还有一些问题。每次引入新参数时，都必须创建一个新的 ConcereteParameter 类。

这不是问题。但是还必须在 CommandBuilder append(ConcreteParameter) 中添加方法。而且我不太喜欢这种依赖。

总结

可以使用参数配置命令。并非每个命令都可以接收相同的参数。所以有些不得不被忽略。应用于命令时（在此实现中，这是通过抛出 UnsupportedOperationException
可应用于某些类的参数在这些类中的使用方式不同（如 FTPCommand 和 HTTPCommand 可能以不同的方式使用 IpParameter）
未来可能会引入新的命令和参数

更新现在的实现是works。但是，如果我有，这不是矫枉过正吗？大约 30 个参数，对于每个参数我必须有一个单独的方法？

如果有，有什么更干净、更灵活的方式/模式来实现这一目标？

【问题讨论】：

标签： java oop design-patterns

【解决方案1】：

什么是参数，什么是参数类型？如果你真的有不同类型的对象作为参数，你可以对它们执行不同的操作，那么你就无法避免使用不同的类来处理它们。如果您的参数仅在命令解释它们的方式上有所不同，但其他主要是String 和Integer 或其他，那么为每个可能的含义设置额外的类肯定是矫枉过正。如果您的参数是某种形式的键值对，那么我会将它们表示为：一个包含参数名称和值的类（或者每个合理的值类型可能一个类）。

如果您可以使用上述方法来减少参数类型的数量，您可能需要考虑使用反射来构建实际的命令。你可以有一个注解@Parameter，你可以用它来装饰你的命令类的setter方法。例如。 @Parameter void setIP(String) 表示该命令接受字符串参数，并将其解释为 IP 地址。如果您使用键值参数，则可以从方法名称派生键，或向注释添加值，或两者兼而有之。使用这样的框架，您可以拥有一个命令构建器，负责将参数提供给适当的设置器。

【讨论】：

【解决方案2】：

即使有一个公认的答案，我觉得您需要了解另一种选择。

我会使用Map 作为上下文对象，并将上下文传递给命令的execute 方法。该命令将简单地通过字符串从Map 中提取它需要的参数。

public interface Command {
   public void execute(Map<String, Object> context);
}

class OneCommandImpl extends Command {
    public void execute(Map<String, Object> context) {
        context.get('p1');
        context.get('p2');
    }
}

这种方法的优点是简单，不需要反思。您可以使用这个接口构建任何需要任意数量参数的命令。主要缺点是 Map 中的值类型不具体。

【讨论】：