基於微信支付、引起的關於請求參數的思考

因爲工做緣由，屢次對接微信生態的相關Api ， 爲了方便因而便本身封裝了一套微信工具類。
在封裝的過程當中，因爲微信支付的一大堆請求參數的設定引起了以下的思考。

通常來講，對於咱們的程序流程，咱們能夠總結以下：

構建參數 -> 發送請求 -> 接收響應

在大多數的業務開發過程當中，咱們習慣於多個方法公用一個RequestBean

舉個栗子

假設咱們如今有一個用戶表，咱們須要對這張表進行增、刪、改、查操做。

用戶表具備以下字段

ID 、 NAME 、 SEX

一般狀況下，咱們會創建一個 UserRequestBean ，這個Bean中包含以上3個字段

新增接口：咱們但願用戶 傳入NAME 、 SEX字段
刪除接口：咱們但願用戶 傳入ID字段
修改接口：咱們但願用戶 傳入ID 、 NAME 、 SEX字段
查詢接口：咱們但願以上3個參數 做爲可選參數進行傳入

在這種場景下對於 服務的消費者來講，就很尷尬了，我只知道須要傳入UserRequestBean，
可是這個Bean中字段太多了，我並不知道在針對不一樣的接口我應該傳入什麼數據，固然能夠經過註釋的方式來解決這樣的問題，不過顯然，若是能夠經過編程式的方式來知曉那麼會至關的好。

咱們先來看下面針對微信支付的一段接口設計：
微信支付設計接口的客戶端使用輔助類

咱們經過上面的視頻發現以下優勢

1: 請求參數 被 區分爲 必傳參數與可選參數
2: 必傳參數在沒有徹底的傳入的狀況下，沒法執行execute函數，也就沒法發送請求
3: 針對必傳參數，能夠強制的約束消費者按照指定的參數順序進行傳入
4: 在參數過多的狀況下，只要傳入了一次以後，那麼將不會再出現相應的傳入函數，這點在參數過多的場景下特別好用。

//TODO 未完待續