开发一个Web应用. 主管要求 所有业务逻辑的Java方法参数和返回类型必须统一为Map类型.
理由是将来扩展时接口不用修改.而且有多返回值的方法也好处理
但是这样一来.
返回一个String都要写成
Map resultMap = doXXXXX(paramMap);
String result = (String)resultMap.get("resultStr");
返回一个VO
Map resultMap = doXXXXX(paramMap);
XXXXVO resultVO = (XXXXVO)resultMap.get("resultVO");
感觉很麻烦.
请问,这种情况要怎么处理? 是否有更好的方案? 这种方式是否有什么弊端.
希望大家从软件工程的角度解答一下!
标准过程化设计:
[code="java"]resultVo = new V0();
int isOk = doXXXXX(paramMap,resultVo);
if(isOk>0){
.....
}[/code]
这样全部用Map来存取的话,程序的映射多了可能会造成结果的成混乱.最好就是把最需要按键值存取的用Map存取,其它的按集合类的优缺点进行使用..
1.0 个人认为
[quote]将来扩展时接口不用修改.而且有多返回值的方法也好处理[/quote]
这样是能带来一定的好处！ 很统一 以后添加什么其他应用或者 改造也方便！
虽然 一般情况下是不建议这么做的！ 但是尝试下 没啥不可以的！ 或者说你们系统的 业务就这这样！需要处理很多的 ｋｅｙ——ｖａｌｕｅ 这样的数据！ 那采取 ｍａｐ 这种方式 是 差强人意的！
软件工程 了解的不多！没办法仔细给你说清楚！
总之： 采取适合你们业务的方法可能才是最合理的！
同上：只有适合的， 没有最好的
个人认为所有的入参和出参用Map不太合适，不够透明，开发人员比较容易混乱，尤其是map中的key的命名还需要指定命名规范。
我建议如果入参出参想统一的话，可以针对业务需要指定两个接口（一个为入参接口，一个为出参接口），在具体业务中对接口进行实现，或定义特有的属性。业务传递时使用接口作为入参和出参。
表面上看好像很灵活，但是实际上却是玩过了头，让人无所适从了。返回值是对函数的一种约束，现在没了约束，反而造成了更大的约束。静态语言编译期类型错误验证的优势完全丧失。
还有，即使日后发生变化，接口本身不用变。但是所有的调用都需要变。而且因为没有静态检查，你连这个接口功能变化引发多少问题都不知道。
你们如果非要这么干。那么必须做好大量的测试以保证修改后不会产生问题。
我觉得你们还不如直接用动态脚本语言编写程序呢。
好处：将返回类型统一，以后扩展容易
弊端：失去了严谨的代码规范，容易造成日后的“地雷”，出现bug难找。
即便要统一接口，我也不会选择map，就像走路走了一半一样。我一般会建立自己的结构，里面可以包含map，也可以包含其他的信息。比如建立一个ResultNode基类，里面加上类型检查，exception等处理。比map好多了。