摘要：所以參數(shù)多多少少影響了的一個(gè)靈活程度和使用復(fù)雜程度。如果多個(gè)參數(shù)，使用能更方便，靈活，簡單。是否使用對(duì)象作為參數(shù)，判斷的指標(biāo)應(yīng)該只有一個(gè)是否方便使用，靈活。即使這樣可能違法了單一指責(zé)原則，但是呼應(yīng)了最少知識(shí)原則。

外在決定是否需要了解內(nèi)在，內(nèi)在決定是否會(huì)一票否決外在。內(nèi)外結(jié)合，好上加好。

開發(fā) API 的時(shí)候，把參數(shù)的名字和位置確定下來，函數(shù)定義就可以說是完成了。因?yàn)?API 使用者來說，只需要知道如何傳遞參數(shù)，以及函數(shù)將返回什么樣的值就夠了，無需了解內(nèi)部。所以參數(shù)多多少少影響了 API 的一個(gè)靈活程度和使用復(fù)雜程度。在設(shè)計(jì) API 的時(shí)候，應(yīng)該怎么設(shè)計(jì)參數(shù)，下面就簡單的寫下，如果大家有不同的想法，歡迎在評(píng)論區(qū)留言。

下面使用的例子，除了原生了 JQuery 的 API。其他的例子都是取自自己封裝的一個(gè)常用函數(shù)庫 ecDo 。歡迎提建議和 star。

其實(shí)什么時(shí)候設(shè)置參數(shù)并沒什么什么說法，規(guī)范。只要覺得用參數(shù)會(huì)使得 API 的使用會(huì)更加的簡單和靈活就用了。

設(shè)置參數(shù)，可能一開始不會(huì)有很好的靈感，但是在使用過程中，用得難受了，自然會(huì)像辦法優(yōu)化。

比如 有 ecDo.count(array|string,item) 這個(gè) API 就是統(tǒng)計(jì)一個(gè)數(shù)組的每個(gè)元素的出現(xiàn)次數(shù)或者字符串每一個(gè)字符的個(gè)數(shù)。

這很容易實(shí)現(xiàn)，代碼也貼下

count(arr) {
    let obj = {}, k, arr1 = []
    //記錄每一元素出現(xiàn)的次數(shù)
    for (let i = 0, len = arr.length; i < len; i++) {
        k = arr[i];
        if (obj[k]) {
            obj[k]++;
        } else {
            obj[k] = 1;
        }
    }
    //保存結(jié)果{el-"元素"，count-出現(xiàn)次數(shù)}
    for (let o in obj) {
        arr1.push({el: o, count: obj[o]});
    }
    return arr1;
},



let strTest1="abbccc"
console.log(ecDo.count(strTest1));
//result:[{el: "a", count: 1},{el: "b", count: 2},el: "c", count: 3}]

但是有些時(shí)候，開發(fā)者并不需要知道所有元素的個(gè)數(shù)，比如就需要知道 "a" 的出現(xiàn)次數(shù)，這個(gè)情況直接返回 "a" 的個(gè)數(shù)就行了，不需要像上面例子一樣，返回一個(gè)數(shù)組。這樣用起來會(huì)舒服一些，改起來也很簡單，只要增加一個(gè)參數(shù)，一個(gè)判斷即可。

count(arr,item) {
    //重復(fù)代碼略
    return item?obj[item]:arr1;
},



let strTest1="abbccc"
console.log(ecDo.count(strTest1),"a");
//result:1

還有一個(gè)常用的 API 是ecDo.clearKeys(obj)--清除對(duì)象中值為‘空’（null, undefined和""）的屬性。

這個(gè)也很容易實(shí)現(xiàn)，

clearKeys(obj) {
    let _newPar = {};
    for (let key in obj) {
        if (obj[key]===0||obj[key]===false||obj[key]) {
            _newPar[key] = obj[key];
        }
    }
    return _newPar;
},


ecDo.clearKeys({1:0,2:2,3:""})
//result:{1: 0, 2: 2}

想必大家也發(fā)現(xiàn)這樣寫法太不靈活了，如果下次要把 0 和 false 的屬性也清空呢？如果下次要把值為 "--" 的屬性也清空呢？這樣就做不到了，所以還要改一下，增加一個(gè)參數(shù) clearValues - 待清空的值。

要使用的一個(gè)函數(shù)

clearKeys(obj, clearValues = [null, undefined, ""]) {
    clearValues.forEach((item, index) => {
        clearValues[index] = Number.isNaN(item) ? "NaN" : item
    });
    let _newPar = {};
    for (let key in obj) {
        //checkValue 看下面定義
        if (!checkValue(obj[key], clearValues)) {
            _newPar[key] = obj[key];
        }
    }
    return _newPar;
},


ecDo.clearKeys({a:"",b:0,c:11})
//result:{b: 0,c: 11}
ecDo.clearKeys({a:"",b:0,c:"--"},["--",""])
//result:{b: 0}
ecDo.clearKeys({a:"",b:0,c:11,d:false},[0,""])
//result:{c: 11,d: false}
ecDo.clearKeys({a:NaN,b:2,c:undefined},[NaN,undefined])
//result:{b: 2}

checkValue 函數(shù)

function checkValue(val, vals) {
    let _val = val;
    if (Number.isNaN(val)) {
        _val = "NaN"
    }
    return vals.indexOf(_val) !== -1;
}

這樣以來，想清除任何值的屬性，這里都可以實(shí)現(xiàn)。

這兩個(gè)注意點(diǎn)可以說是平常接觸最頻繁的，也是最無可辯解的。

首先參數(shù)的數(shù)量，在不影響 API 使用的情況下肯定是能少就少，越少越好。因?yàn)閰?shù)的越少，API 的記憶成本越低，調(diào)用也更加便利。

參數(shù)能少就少，越少越好，是有前提的--不影響 API 的使用。如果多個(gè)參數(shù)， API 使用能更方便，靈活，簡單。多個(gè)參數(shù)就多個(gè)參。

然后參數(shù)的前置性，就是參數(shù)相關(guān)性越高，越不能省略的，就越要放在前面。雖然可以把可省略參數(shù)放后面，但是這樣問題可能會(huì)很多。

什么時(shí)候該使用對(duì)象作為函數(shù)的參數(shù)，暫時(shí)發(fā)現(xiàn)是兩種情況。

1.參數(shù)過多的時(shí)候

2.參數(shù)不固定的時(shí)候

比如 ajax 的參數(shù)，至少至少也有 5 個(gè)。url-請(qǐng)求鏈接，method-請(qǐng)求方式，data-請(qǐng)求參數(shù)，success-成功回調(diào)，fail-失敗回調(diào)。如果不使用對(duì)象作為參數(shù)，完整的寫法，是下面這樣

ajax(url,method,data,success,fail)

但這5個(gè)參數(shù)里面，除了 url ，其他參數(shù)都可以省略或者默認(rèn)。如果只需要傳 url 和 success，需要像下面這樣寫

ajax(url,"","",success)

因?yàn)閰?shù)的順序不能亂，所以就要這樣寫。這樣多難受就不說了，如果參數(shù)過多，參數(shù)看著會(huì)很長，容易搞錯(cuò)參數(shù)順序，就會(huì)出現(xiàn)問題了。

如果使用對(duì)象傳參，就舒服很多了。

ajax({url:url,success:function(){}})

這樣寫的會(huì)多一點(diǎn)，但是好處也有。首先用戶還是需要記住參數(shù)名，但不用關(guān)心參數(shù)順序，不用擔(dān)心參數(shù)過多。然后就是開發(fā)者想增加多少參數(shù)都比較方便，也不用關(guān)心參數(shù)后置的問題。

是否使用對(duì)象作為參數(shù)，判斷的指標(biāo)應(yīng)該只有一個(gè)：是否方便使用，靈活。

什么時(shí)候應(yīng)該設(shè)計(jì)默認(rèn)值？也分幾種情況討論

首先是，一個(gè)參數(shù)值出現(xiàn)頻率比其他情況大的時(shí)候。比如有一個(gè) ecDo.encrypt(str,regIndex,repText） 的 API，作用很簡單，就是對(duì)字符串的特定位置進(jìn)行加密。比如經(jīng)常會(huì)遇到隱藏用戶的手機(jī)號(hào)碼的需求。

電話號(hào)碼隨便編造的

ecDo.encrypt("18819233362","3,7")
//result:188*****362

ecDo.encrypt("18819233362","3,7","+")
//result:188+++++362

ecDo.encrypt("18819233362","4")
//result:*****233362

ecDo.encrypt("18819233362","-4")
//result:188192*****

在這個(gè) API 里面 ，第三個(gè)參數(shù) repText 可能大多數(shù)情況都是使用 。如果不對(duì) repText 設(shè)置默認(rèn)值，如果每一次都傳一個(gè) ，不但寫的多，看得也難受。

還有一種情況，從特定位置執(zhí)行到結(jié)尾結(jié)束的時(shí)候。比如原生的 substr(start,length) ，第一個(gè)參數(shù)是開始字符的下標(biāo)，第二個(gè)參數(shù)是截取的長度。如果省略，就從開始位置截取到結(jié)尾。這樣就算是一種方便。

這里說的參數(shù)多態(tài)跟繼承方面的多態(tài)有點(diǎn)區(qū)別

參數(shù)多態(tài)這個(gè)很常見，目的很簡單，就是通過不同的傳參方式讓一個(gè)函數(shù)進(jìn)行不同的操作?？吹竭@里，可能大家一下子就想到 splice。因?yàn)橐粋€(gè) splice 可以實(shí)現(xiàn)數(shù)組的增加，刪除，替換

//刪除
let arr=[1,2,3,4,5,6]
arr.splice(0,1)
//result:arr:[2, 3, 4, 5, 6]

//替換
arr=[1,2,3,4,5,6]
arr.splice(2,1,0)
//result:arr:[1, 2, 0, 4, 5, 6]

//增加
arr=[1,2,3,4,5,6]
arr.splice(2,0,0)
//result:arr:[1, 2, 0, 3, 4, 5, 6]

但是 splice 應(yīng)該并不算是參數(shù)多態(tài)，只能算是一些技巧的一個(gè)寫法。

表現(xiàn)出參數(shù)多態(tài)的，比如 JQuery 的 attr 。既可以獲取屬性的值，也可以設(shè)置屬性的值。

//獲取 dom 元素 id 的值
$(dom).attr("id")
//設(shè)置 dom 元素 id 的值
$(dom).attr("id","domId")

JQuery 把多態(tài)表現(xiàn)得更好的應(yīng)該是 $() 。JQuery 火的原因，跟這個(gè) $() 有很大的關(guān)系，只要是合法的選擇器，頁面存在這個(gè)元素，就能找到。讓選擇元素變得非常簡單。

關(guān)于 $() 的強(qiáng)大特性，可參考 jQuery 選擇器

在自己封裝 API 的時(shí)候，也會(huì)遇到操作 cookie 的一系列操作（設(shè)置，獲取，刪除）。之前是這樣

ecDo.setCookie(cookieName,value,day)//設(shè)置（cookie名稱，cookie值，有效的天數(shù)）
ecDo.getCookie(cookieName)//獲取
ecDo.removeCookie(cookieName)//刪除

現(xiàn)在是這樣

ecDo.cookie(cookieName,value,day)//設(shè)置（cookie名稱，cookie值，有效的天數(shù)）
ecDo.cookie(cookieName)//獲取
ecDo.cookie(cookieName,value,-1)//刪除

這樣使用起來，就比之前簡單一點(diǎn)，相當(dāng)于只是記住一個(gè) API 就可以了。

參數(shù)的多態(tài)，就是讓 API 的指責(zé)會(huì)根據(jù)參數(shù)的情況進(jìn)行改變。相當(dāng)于把相似職責(zé)的 API 給合并成一個(gè)。不需要給用戶提供出太多 API，方便用戶的使用。即使這樣可能違法了單一指責(zé)原則，但是呼應(yīng)了最少知識(shí)原則。能讓 API 的使用盡可能簡單化了。

參數(shù)多態(tài)就是把相似職責(zé)的 API 給合并成一個(gè)。但是有時(shí)候并不適合使用。更適合把合并的 API 拆分成幾個(gè)。

比如之前封裝常用 API 的時(shí)候。有一個(gè)去除字符串空格的 API : ecDo.trim(str,type) （str-待處理的字符串，type-去除空格的類型----1-左右空格，2-所有空格，3-左空格，4-右空格） 。

使用形式

ecDo 是我封裝的一個(gè)常用函數(shù)庫。

let str=" 守 候 ";
console.log(ecDo.trim(str,1));//"守 候"
console.log(ecDo.trim(str,2));//"守候"
console.log(ecDo.trim(str,3));//"守候 "
console.log(ecDo.trim(str,4));//" 守候"

這樣使用的話，想必大家都看到問題了。1 2 3 4 是什么鬼？就算知道是什么鬼，也要把這幾個(gè)鬼記住。記憶成本大，調(diào)用也不方便。后來就拆分成四個(gè)函數(shù)了。

let str=" 守 候 ";
console.log(ecDo.trim(str));//"守 候"
console.log(ecDo.trimAll(str));//"守候"
console.log(ecDo.trimLeft(str));//"守候 "
console.log(ecDo.trimRright(str));//" 守候"

這樣雖然多了幾個(gè) API 但是使用起來簡單了。記憶成本也比之前少。是否設(shè)置參數(shù)多態(tài)，還是要看調(diào)用的情況而言。

好了，關(guān)于 API 參數(shù)方面的東西就暫時(shí)寫到這里了，這部分的內(nèi)容不多，所以篇幅不是很長，也容易理解。但是參數(shù)這個(gè)話題也相對(duì)開放，如果大家有什么好的想法。歡迎在評(píng)論區(qū)留言。

-------------------------華麗的分割線--------------------

想了解更多，和我交流，內(nèi)推職位，請(qǐng)?zhí)砑游椅⑿??；蛘哧P(guān)注我的微信公眾號(hào)：守候書閣