首先宣告，本乾貨的觀點僅代表個人觀點，拿出來和大家嘮叨嘮叨。
最近在寫**的時候，發現了乙個有趣的事情。就是我建立了乙個新的函式，但是因為各種需求，各種功能設計的原因，函式的形引數目達到了10多個之多。
而這個時候，由於本函式是乙個公共函式，所以被呼叫的地方十分多，當這個函式的形參需要增刪改的時候，可謂牽一髮而動全身（當然，出現這種情況就應該想到是不是設計有問題了，耦合度這麼高，但這次先不談這個），所以針對這種情況，我分別思考了3種最常用的傳參方式。
第一種
直接傳參,每個引數乙個個的排好隊寫上，例如：
來自睿江雲計算
優點：
傳入的引數清晰，明確可以知道傳入引數有多少個，分別代表什麼意思，從語義上一目了然。
呼叫方便，呼叫者直接傳參，無需對引數進行處理加工。
對新手來說更加友好，更容易理解。
缺點：
形參太多，**失去了美感，太隨性了。
當某個引數需要改動的時候，簡直是牽一髮而動全身，比如$param5改為選填引數，並且預設值為test：
來自睿江雲計算
缺點很明顯，這個時候由於php引數順序的問題，選填引數必須在最後，所以所有呼叫者都需要起碼把原來的param5去除，放在引數最後位置，改動代價高。
總結：當引數少的時候，可以使用直接乙個個引數傳遞，這樣是最好的，但是當引數過多，或者改動需求大的時候，這種方法無疑是繁重的。
所以針對上面這種，當引數數量過多的時候，可以使用方法二：
第二種
把引數組合成乙個陣列的形式，整乙個陣列當做引數進行傳遞。例如：
優點：
**更加整潔了。
**更加靈活，現在就算有乙個引數需要改動，也無需修改函式的引數，只需要在呼叫者處增加引數即可。
缺點：
3. 沒有了php的語法限制。例如沒有了string這種的型別限制，沒有了帶預設值的選填引數的語法限制。這樣子就需要你做多一層引數的檢查。
4. 引數可讀性差了。函式的陣列裡面有哪些引數是不能通過形參看出來的，需要檢視呼叫者的陣列組成。
總結：總體來說這種方法可以解決第一種傳參方式的弊端，但是也自身帶來了更加大的弊端，引數的限制需要另外增加一層鉤子去處理，可以說是價效比比較低的一種方法。
綜合上面兩種方法的利弊，我總結出第三種傳參方式：
第三種
傳遞乙個資料結構物件當做引數，例如：
優點：
5. 引數為乙個資料結構，保證資料的完整性。就是傳進來的資料結構必然能包含所需的引數。
6. 當引數需要更加或者減少的時候，只需要修改資料結構模型的物件屬性即可。
7. 把資料的控制和限制可以統一放在模型層進行處理。
缺點：
1.可能需要多個資料結構模型。
總結：總體來說這種方法可以比較全面的解決第一第二種方法的弊端，就是需要建立多種資料結構模型，增加了**量。
以上就是介紹的3種傳參的種類，這是乙個細節性，場景性的問題，不知道能不能明白個中意思呢？
vue三種傳參方式
子元件通過 route.name接收引數 子元件接收 第二種 通過router link中的to屬性 對應路由配置 通過路由中的name屬性來確定匹配的路由，通過params來傳遞引數 params是乙個物件，裡面是key value的形式 gohome 子元件接收 this.route.param...
oc的三種反向傳參方式
一 傳值 在 nextviewcontroller.h中 1,定製傳值協議 protocol nextviewcontrollerdelegate bool nextviewcontrollwithcolor uicolor color end 2,定義 屬性 property weak,nonat...
Vue路由傳參的三種方式
第一種 父元件 getdescribe1 id 路由 另外路由需要配置，在path中新增 id來對應 router.push 中path攜帶的引數 這種方法引數值會跟在url後面，子元件通過this.route.params.id獲取傳過去的引數 第二種父元件 通過路由屬性中的name來確定匹配的路...