高手帮我看一下这样的接口设计合不合理

Question

public ResultBean doSomeThing(RequestBean bean);
由于接口参数经常会变动(或很大可能会变动),为了保持接口一设计就不再去改参数,所以我想将参数设计成bean
这样参数的变动只需要维护相应的bean对像即可,接口一设计后就可以不再进行修改,这样设计主要也是考虑在接口设计后
已经有调用者调用的情况下,对参数的扩充的设计.大家觉得这样设计合不合理?
还有ResultBean也是一样,主要是考虑返回的是对像,而对像里的属性也不定的情况.
比如既要返加一个int又要返回一个Hashtable的情况.
各位高手麻烦从设计和合理性的角度帮我分析一下这样的接口设计有没什么问题,谢谢了

Answer 1

软件设计有个开闭原则
就是你编写的程序要对扩展打开，对修改关闭
对接口的修改是要关闭的
返回值不同，你可以在返回值外包装一个ResultBean的实现，再返回

Answer 2

何不启用JDK1.5的新特性：泛型？interface Test{
    public abstract <ORIG, DEST> DEST doSomeThing(ORIG orig);
}

Answer 3

hyb15910830861不知道是我不明白你的意思,还是你误解了我的想法.
你能不能再解释一下用泛型跟我这里的接口参数和返回值灵活修改有什么关系?

Answer 4

个人感觉不太合理.你设计那个接口和这个有区别吗？
public Object doSomething(Object obj);我倒觉得你不如设计成 几个方法重载，来解决参数和返回值变化问题！
PS:接口中的方法要有意义啊!

Answer 5

我觉得合理.为什么呢,因为面向接口编程都不用说了吧.如果你传来一个接口,我可以让所以的javabean都实现这个接口,而这个接口我可以写空.不写方法,此时就充当一个中介..这样我就可以根据自己需要哪个javabean来实例就可以了..我在代码中是用此方法..合理的解释是 面向接口 编程!!!

Answer 6

我决定还是比较合理的。
感觉你的设计和DBUtils中的Interface ResultSetHandler的设计思想差不多。

Answer 7

以Object做为参数和返回值，是一种类型不安全的编码方式。
而楼主已经指定了具体的RequestBean类做为参数和返回值，在这一点上是比较合理的。
尽管在函数的命名似乎有些不妥。顺便To楼主：如果你确定想返回多于一个的参数，那就应该选择类封装的形式。
其实说到代码的开闭原则并没有绝对的所谓“对修改关闭，对开放扩展”，这种开闭原则就相当于一个球在真空环境下滚动，属于一种理想化的情境！毕竟在一个项目中，不太可能出现每个类相互独立的，有关联就必然有耦合。因此建议楼主不必太拘泥于书面知识。其实“对修改关闭，对开放扩展”还应该加上“尽量”进行修饰。本人的意思就是说不可能绝对做到真正的开闭原则，而是尽最大努力去靠近这个原则！