摘要:上一個版本的問題接這篇文章,聊聊參數檢查工具的完善。最終實現了這樣的效果檢查是否在區間與的交集內檢查是否在區間與的并集內檢查是否是數組并且長度大于檢查是否不是之間的偶數即
上一個版本的問題
接這篇文章,聊聊參數檢查工具 param-check 的完善。
按照之前的接口設計,鏈式調用表示“與”,參數表表示“或”,自然產生了一個問題——如果我要表達“(A與B)或(C與D)”這樣的邏輯組合應該怎么辦?
以及,由于 not 調用只對它后面的第一個調用生效,那么如果我要實現“非(A與B)”,該怎么辦?
總結起來,實際上就是給邏輯表達式加括號的問題。
or 和 and 方法為了自由表達與或關系,我們需要擴展一下規則。分析可知,函數調用的參數表是一個天然的括號,所以只用來表達“或”太奢侈了。我們添加方法 or 和 and,使之能表達與和或。但是這里有個問題,param-check 目前的接口都是即時計算的,如果你把調用串當做參數傳遞,沒有傳進去之前已經計算完了,異常捕獲不到,沒法實現邏輯關系。比如:
check(a).or(check(a).gt(1).lt(3), check(a).gt(2).lt(4));
上面的代碼是沒法實現 or 的。
解決方法比較容易想到的有兩個:
改變接口模式,不再拋出異常,二是返回 false。這樣 or 和 and 就很容易實現了,但是鏈式調用就沒法實現了。
提取 check 的調用路徑,使得一個檢查過程能保存在一個對象(高階函數)里,當做參數傳到其它函數中,本質上這是一種函數式編程方法。如果不考慮到書寫方便,這是很容易實現的:
function myCheck(a) { check(a).gt(1).lt(3); } function myCheck2(a) { check(a).is("string"); } +function (a) { check(a).or(myCheck, myCheck2); }(2);“使用鏈式調用記錄鏈式調用路徑”
顯然上面的寫法非常不方便,所以我實現了一種更好用的接口,使用同樣的鏈式調用方式,實現調用路徑提取和參數緩存。具體的實現方式在這篇文章里。最終實現了這樣的效果:
// 檢查 param 是否在區間(1,3) 與 (2,4) 的交集內 check(param, "param").and(check.policy.gt(1).lt(3), check.policy.gt(2).lt(4)); // 檢查 param 是否在區間(1,2) 與 (3,4) 的并集內 check(param, "param").or(check.policy.gt(1).lt(2), check.policy.gt(3).lt(4)); function myCheck(obj) { return obj.length > 4; } // 檢查 param 是否是數組并且長度大于 4 check(param, "param").and(check.policy.is("array"), myCheck); // 檢查 param 是否*不是*[1,3]之間的偶數(即2) check(param, "param").not.and( check.policy.is("number").not.lt(1).not.gt(3), function (obj) { return obj % 2 === 0; });
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/86403.html
摘要:本文嘗試編寫一種參數檢查工具,期待能緩解類似問題。為了實現鏈式調用,返回的是一個特殊的包裝對象。如果要打印出檢查失敗的參數名,需要寫成。由于德摩根定律的存在,后的參數表實際上在表達與的關系,比如表示的是參數既不為也不為。 綜述 javascript 屬于弱類型語言,參數的類型錯誤只能在運行期發現。當你需要 expose 非常健壯的接口給外部,或者在調試較大項目的時候,你可能會懷念強類型...
摘要:但好在還給我們提供了一個方法,每一個對象都有這樣一個方法,專門用來判斷某個屬性是否是該對象的私有屬性。如果你想要用對象字面形式,你只能在創建對象時定義訪問器屬性。在中,我們使用凍結一個對象,并且使用來判斷一個對象是否被凍結。 說完了對象那些不常用的冷知識,是時候來看看JavaScript中對象屬性有哪些有意思的東西了。 不出你所料,對象屬性自然也有其相應的特征屬性,但是這個話題有點復雜...
摘要:從而輔助整個團隊提高代碼質量統一代碼規范。如果你的團隊還沒有這么一份代碼評審清單,也許這正是你需要的如果你的團隊已經有了代碼評審參照標準,這份清單也許能起到錦上添花的效果。如果違反這個規則,那么代碼會很難被測試或者重用。 前言 ? 前端團隊有評審代碼的要求,但由于每個開發人員的水平不同,技術關注點不同,所以對代碼評審的關注點不同,為了保證代碼質量,團隊代碼風格統一,特此擬定...
摘要:而測試驅動開發技術并不只是單純的測試工作。需求向來就是軟件開發過程中感覺最不好明確描述易變的東西。這里說的需求不只是指用戶的需求,還包括對代碼 可能很多人和我一樣, 首次聽到前端架構這個詞, 第一反應是: 前端還有架構這一說呢? 在后端開發領域, 系統規劃和可擴展性非常關鍵, 因此架構師備受重視, 早在開發工作啟動之前, 他們就被邀請加入到項目中, 而且他們會跟客戶討論即將建成的平臺的...
閱讀 844·2023-04-25 21:21
閱讀 3226·2021-11-24 09:39
閱讀 3067·2021-09-02 15:41
閱讀 1993·2021-08-26 14:13
閱讀 1827·2019-08-30 11:18
閱讀 2768·2019-08-29 16:25
閱讀 506·2019-08-28 18:27
閱讀 1580·2019-08-28 18:17