实践中的重构03_批处理方法默认约定

最近看代码的时候，发现了一个奇怪的现象。关于调用批处理接口的问题。

如调用一个查询用户信息的接口为
UserInfo getUserInfo(String id)

则对应的批处理接口为
List<UserInfo> getUserInfoByIds(List<String> ids)

很多地方对该返回值进行了校验，即用for循环比对返回的UserInfo进行比对，担心返回的列表的长度和传入参数的长度不同，担心返回的列表的顺序和传入参数的顺序不同。

我觉得这样大可不必。调用批处理接口，应该是符合common sense的。
即可以返回一个null,可以返回一个empty list,其他情况都是返回一个大小和传入参数个数相等且顺序一致的列表。

如果有特殊情况，应该在方法的接口定义中特别声明，这样调用方的code会比较清晰好读，也符合一般人的直觉。让调用方做校验，这样的想法如果没有很强大的理由，还是不要的好，因为遵守默认约定，有可能服务方的代码会稍微复杂一点，但是考虑到多处调用方的代码的简洁和易读，这点代价完全是值得的。

评论

7 楼 抛出异常的爱 2010-09-10  

zhang_xzhi_xjtu 写道

所以我就强调说要按照顺序返回 如果不按顺序返回的话 map<String,UserInfo>这种方式倒是挺好的

LinkedHashMap <string ,UserInfo> getUserInfoByIds(List<String> ids)

这样就约束有序了.....

不过语义多了排除无效 id 这个多余的语义....

6 楼 zhang_xzhi_xjtu 2010-09-10  

所以我就强调说要按照顺序返回 如果不按顺序返回的话 map<String,UserInfo>这种方式倒是挺好的

5 楼 cai824 2010-09-10  

在返回的时候，个人感觉还是按照传过去的List<String> ids 的size进行返回比较好，这样页面上反映结果比较清晰。还有就是不知道在按照 ids 顺序返回结果的时候，有什么好的方法？

4 楼 zhang_xzhi_xjtu 2010-09-09  

这样是解决了一些问题 但是还是有问题的
比如要是要用前一个批处理的返回值当作下一个批处理的参数。

所有我还是提倡严格遵守默认约定。

PS,ids中有不存在的id时,可以返回null.

3 楼 beneo 2010-09-09  

赞赞赞赞赞赞赞赞赞赞

2 楼 zhxing 2010-09-09  

引用

返回map<String,UserInfo>语义才饱满.

这个赞成。。也算是一种比较优雅的方式

1 楼 抛出异常的爱 2010-09-09  

zhang_xzhi_xjtu 写道

最近看代码的时候，发现了一个奇怪的现象。关于调用批处理接口的问题。

如调用一个查询用户信息的接口为
UserInfo getUserInfo(String id)

则对应的批处理接口为
List<UserInfo> getUserInfoByIds(List<String> ids)

很多地方对该返回值进行了校验，即用for循环比对返回的UserInfo进行比对，担心返回的列表的长度和传入参数的长度不同，担心返回的列表的顺序和传入参数的顺序不同。

我觉得这样大可不必。调用批处理接口，应该是符合common sense的。
即可以返回一个null,可以返回一个empty list,其他情况都是返回一个大小和传入参数个数相等且顺序一致的列表。

如果有特殊情况，应该在方法的接口定义中特别声明，这样调用方的code会比较清晰好读，也符合一般人的直觉。让调用方做校验，这样的想法如果没有很强大的理由，还是不要的好，因为遵守默认约定，有可能服务方的代码会稍微复杂一点，但是考虑到多处调用方的代码的简洁和易读，这点代价完全是值得的。

ids中有不存在的id时 返回的list与传入list个数是不同的.
使用者不校验使用 页面有时会 混乱......不能对齐.
返回map<String,UserInfo>语义才饱满.