共计 687 个字符，预计需要花费 2 分钟才能阅读完成。
由于工作原因，多次对接微信生态的相关 Api，为了方便于是便自己封装了一套微信工具类。在封装的过程中，由于微信支付的一大堆请求参数的设定引发了如下的思考。
一般来说，对于我们的程序流程，我们可以总结如下：
构建参数 -> 发送请求 -> 接收响应
在大多数的业务开发过程中，我们习惯于多个方法公用一个 RequestBean
举个栗子
假设我们现在有一个用户表，我们需要对这张表进行增、删、改、查操作。
用户表具有如下字段
ID、NAME、SEX
通常情况下，我们会建立一个 UserRequestBean，这个 Bean 中包含以上 3 个字段
新增接口：我们希望用户 传入 NAME、SEX 字段删除接口：我们希望用户 传入 ID 字段修改接口：我们希望用户 传入 ID、NAME、SEX 字段查询接口：我们希望以上 3 个参数 作为可选参数进行传入
在这种场景下对于 服务的消费者来说，就很尴尬了，我只知道需要传入 UserRequestBean，但是这个 Bean 中字段太多了，我并不知道在针对不同的接口我应该传入什么数据，当然可以通过注释的方式来解决这样的问题，不过显然，如果可以通过编程式的方式来知晓那么会相当的好。
我们先来看下面针对微信支付的一段接口设计：微信支付设计接口的客户端使用辅助类
我们通过上面的视频发现如下优点
1: 请求参数 被 区分为 必传参数与可选参数 2: 必传参数在没有完全的传入的情况下，无法执行 execute 函数，也就无法发送请求 3: 针对必传参数，可以强制的约束消费者按照指定的参数顺序进行传入 4: 在参数过多的情况下，只要传入了一次之后，那么将不会再出现相应的传入函数，这点在参数过多的场景下特别好用。
//TODO 未完待续
