基于微信支付、引发的关于请求参数的思考

由于工作原因，多次对接微信生态的相关Api ， 为了方便于是便自己封装了一套微信工具类。
在封装的过程中，由于微信支付的一大堆请求参数的设定引发了如下的思考。

一般来说，对于我们的程序流程，我们可以总结如下：

构建参数 -> 发送请求 -> 接收响应

在大多数的业务开发过程中，我们习惯于多个方法公用一个RequestBean

举个栗子

假设我们现在有一个用户表，我们需要对这张表进行增、删、改、查操作。

用户表具有如下字段

ID 、 NAME 、 SEX

通常情况下，我们会建立一个 UserRequestBean ，这个Bean中包含以上3个字段

新增接口：我们希望用户 传入NAME 、 SEX字段
删除接口：我们希望用户 传入ID字段
修改接口：我们希望用户 传入ID 、 NAME 、 SEX字段
查询接口：我们希望以上3个参数 作为可选参数进行传入

在这种场景下对于 服务的消费者来说，就很尴尬了，我只知道需要传入UserRequestBean，
但是这个Bean中字段太多了，我并不知道在针对不同的接口我应该传入什么数据，当然可以通过注释的方式来解决这样的问题，不过显然，如果可以通过编程式的方式来知晓那么会相当的好。

我们先来看下面针对微信支付的一段接口设计：
微信支付设计接口的客户端使用辅助类

我们通过上面的视频发现如下优点

1: 请求参数 被 区分为 必传参数与可选参数
2: 必传参数在没有完全的传入的情况下，无法执行execute函数，也就无法发送请求
3: 针对必传参数，可以强制的约束消费者按照指定的参数顺序进行传入
4: 在参数过多的情况下，只要传入了一次之后，那么将不会再出现相应的传入函数，这点在参数过多的场景下特别好用。

//TODO 未完待续