本文是《微信支付回调里，为什么一行 data.order.amount 胜过五层判空》的思路延伸
做接口对接久了，我越来越反感一种代码：
明明只是取几个字段，却写成这样：
Object dataObj = response.get("data");
if (dataObj instanceof Map) {
Map<String, Object> data = (Map<String, Object>) dataObj;
Object orderObj = data.get("order");
if (orderObj instanceof Map) {
Map<String, Object> order = (Map<String, Object>) orderObj;
Object amountObj = order.get("amount");
if (amountObj instanceof Integer) {
Integer amount = (Integer) amountObj;
}
}
}
它当然没错。但它有一个很严重的问题：
它会不断打断你对业务本身的思考。
更麻烦的是，这种打断不是只发生在第一次开发时：很多接口代码第一次写出来，也许只是显得啰嗦一点。真正难受的是，过几天接口结构一变，你还得回头钻进那一大段旧代码里，重新确认每一层判空、每一个中间变量、每一次强转，到底是不是还成立。
这是一种重复、枯燥，而且很容易出错的劳动。
做接口真正复杂的，从来不是取值，而是：
- 状态怎么流转
- 幂等怎么保证
- 数据是否合法
- 异常怎么补偿
经常！不管你是用Map来承载,还是用DTO, 我们都要把一些精力浪费在这些无聊的事情上：
- 这一层是不是 null？
- 这个值是什么类型？
很多时候接口变动，其实只是结构调整，例如
某个字段往里挪一层，某个对象换个名字，或者外面又包了一层节点，本质上都不算业务重写。
比如说：
data.order.amount -> data.payment.amount.value
按理说，这种改动应该只是：
改一个路径。
但如果你的代码是层层展开的：
你往往得回去：
- 重读那一大段旧代码
- 重新确认中间变量和判空
- 担心漏掉某个强转或某个分支
- 再做一轮回归测试
本来只是结构小改，最后却变成一次无聊的结构解析工作。
我想了个办法：一行路径访问，让变更点一眼可见
这样写
JSONMap response = new JSONMap(body);
Integer amount = response.getInt("data.order.amount");
String orderId = response.getStr("data.order.orderId");
String openid = response.getStr("data.user.openid");
只需要关心“这个字段到底从哪里取”就行了！！！
字段结构变了？没事，改这里就完事
response.getInt("data.payment.amount.value")
凉快乎？那是相当地凉快呀！ 不用补判空，不用新增中间变量，也不用重新梳理整段解析逻辑
这不只是“代码更短”
真正的价值是：
你的注意力终于只需要 留给业务 了 接口结构变了，你顺着路径就知道该改哪里了
而不是：
读旧代码 -> 判断 data空不空 → 判断 order空不空 → 判断类型对不对 → 再取 amount
这种清晰感，在要维护很多接口、很多字段的时候，会被不断放大。
结论
这才是做编程工作最宝贵的东西：
心流 —— 不该被无聊的简单工作打断的连续思路！
关于接口对接这件事，你们遇到过最头疼的问题是什么？
附：文中示例所用工具
- 项目：dlz-kit
- 转自官网：dlzio.top
- Maven：
top.dlzio:dlz-kit - GitHub：github.com/dingkui/dlz…
- Gitee：gitee.com/dlzio/dlz-k…
