如何以一种干净的方式来模拟越来越多的使用参数的命令 [英] How to model an increasing amount of Commands with Parameters in a clean way

查看:82
本文介绍了如何以一种干净的方式来模拟越来越多的使用参数的命令的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

这是如何在这个Builder实现中摆脱instanceof

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

There are still some problems with this design. Every time a new parameter is introduced, one must create a new ConcereteParameter class.

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

That's not a problem. But one must also add method in the CommandBuilder append(ConcreteParameter). And I'm not quite liking that dependency.

总结


  • 命令可以配置参数。不是每个命令都可以接收相同的参数。所以有些不得不被忽视。当应用到一个命令(在这个实现中,这是通过抛出一个 UnsupportedOperationException

可以应用于某些类在这些类中使用不同(像FTPCommand& HTTPCommand可能以不同的方式使用IpParameter)

Parameters that can be applied to certain classes are used differently in those classes (Like FTPCommand & HTTPCommand might use IpParameter in a different way)

在将来的新命令和参数可能被引入

In the future new Commands and Parameters might be introduced

更新
现在执行工作。但是,如果我有
约30个参数,那么每个参数我必须有一个单独的方法吗?

Update The implementation as it is now works. But isn't it overkill that if I have about 30 parameters, that for every parameter I have to have a separate method?

如果有,
什么是更干净,更灵活的方式/模式来实现这一点?

If there is, What is a more clean and more flexible way/pattern to achieve this?

推荐答案

你有什么参数,什么是参数类型?如果你真的有不同类型的对象作为参数,使用不同的操作可以对它们执行,那么你不能避免有diff处理他们的课程。如果您的参数仅在命令解释方式上有所不同,但主要是 String Integer 或任何,然后每个可能的意义的额外课程肯定是过度的。如果你的参数是某种形式的键值对,那么我将会代表它们:一个类(或者每个合理的值类型可能有一个)包含参数的名称和值。

What is a parameter for you, and what is a parameter type? If you really have different kinds of objects as parameters, with different operations you may perform on them, then you cannot avoid having different classes to handle them. If your parameters only differ in how the commands interpret them, but otherwise are mostly String and Integer or whatever, then having extra classes for each possible meaning is surely overkill. And if your parameter are some form of key-value pair, then I'd represent them as such: a single class (or perhaps one for each reasonable value type) to contain the name and the value of the parameter.

如果可以使用上面的方法来减少参数类型的数量,那么您可能需要考虑反映实际的命令构建。您可以使用用于装饰命令类的setter方法的注释 @Parameter 。例如。 @Parameter void setIP(String)将意味着该命令接受一个String参数,并将其解释为我的IP地址。如果使用键值参数,则可以从方法名称导出密钥,或向注释添加一个值,或者两者。使用这样一个框架,您可以有一个命令生成器,它将负责将参数提供给适当的设置器。

If you can use the above to reduce the number of parameter types, you might want to consider reflection for the actual command building. You could have an annotation @Parameter which you use to decorate setter methods of your command classes. E.g. @Parameter void setIP(String) would mean that the command accepts a String parameter, and will interpret that as am IP address. If you use key-value parameters, you can either derive the key from the method name, or add a value to the annotation, or both. Using such a framework, you could have a single command builder which would take care of feeding parameters to the appropriate setters.

这篇关于如何以一种干净的方式来模拟越来越多的使用参数的命令的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆