摘要:策略模式實現的也是類似的場景。第二個部分是環境類不變,接收客戶的請求,隨后把請求委托給某一個策略類。參考文章設計模式設計模式與開發實踐設計模式系統講解與應用本文首發,期待作者以樂之名本文原創,有不當的地方歡迎指出。
策略模式:定義一系列的算法,把它們一個個封裝起來,并且使它們可以相互替換
生活小栗子:諸葛錦囊
諸葛給劉備的錦囊妙計,遇到任何困難都有應對計策。策略模式實現的也是類似的場景。
再來一栗:給喜歡的女生買冰淇淋,事先不了解其喜好,只能集齊各種味道,總會命中。就是比較 “費錢”,這也是策略模式的缺點,需事先考慮所有應對場景。
模式特點策略類:算法封裝成獨立的函數/對象
環境類:根據不同參數調用對應的策略函數/對象執行
模式實現實現方式:一個基于策略模式的程序至少由兩部分組成,第一個部分是一組策略類 Strategies(可變),策略類封裝類具體的算法,并負責具體的計算過程。第二個部分是環境類 Context(不變), Context 接收客戶的請求,隨后把請求委托給某一個策略類。
假設我們一個開發團隊,人員組成包括(開發組長,后端,前端,測試)。開發組長領取開發任務(不變),但具體的任務執行人員可根據類型劃分(可變)。
比如開發任務有以下幾項:
優化服務器緩存(后端任務)
優化首屏加載速度(前端任務)
完成系統并發測試(測試任務)
開發組長會根據任務類型,分發到對應的開發人員頭上,組長不承擔具體開發任務。所以每一個開發人員就承擔 Strategy 的作用(獨立的任務執行),而組長擁有并可支配所有開發人員的資源,充當 Context 的角色。團隊每一個開發人員“組合”起來就是一個 Strategies 類(執行開發任務)。 這個 Strategies 是可變的,如果說后續開發任務需要安卓的、IOS的支持,只要添加安卓、IOS開發人員配置即可(可擴展)。
// 策略類(開發人員) var Strategies = { "backend": function(task) { console.log("進行后端任務:", task); }, "frontend": function(task) { console.log("進行前端任務:", task); }, "testend": function(task) { console.log("進行測試任務:", task); } }; // 環境類(開發組長) var Context = function(type, task) { typeof Strategies[type] === "function" && Strategies[type](task); } Context("backend", "優化服務器緩存"); Context("frontend", "優化首頁加載速度"); Context("testend", "完成系統并發測試");
上述代碼帶來的好處:
算法獨立封裝,任務分發;
開發組長不承擔具體開發任務(只做頂層設計,不跟年輕人搶飯碗)
復用性更好,不局限于 Context 調用;
開發人員不愁下家(去哪寫代碼都是寫代碼)
策略模式的另一個好處就是,消除了大部分的 if...else / switch...case 條件分支語句,代碼閱讀性提高。
// 沒有使用策略模式的組長... var Context = function(type, task) { if (type === "backend") { // 把后端給我叫來 } else if (type === "frontend") { // 把前端給我叫來 } else if (type === "testend") { // 把測試給我叫來 } }
JavaScript 中,函數作為“一等公民“,也稱“一等對象”。JavaScript 中 ”高階函數“ 應用中,函數可被作為變量或參數進行傳遞或調用。因此在 JavaScript 中,我們可將算法封裝成獨立的函數,并將它作為參數傳遞給另一個函數調用。
// 封裝獨立的函數 var backend = function(task) { console.log("進行后端任務:", task); }; var frontend = function(task) { console.log("進行前端任務:", task); }; var testend = function(task) { console.log("進行測試任務:", task); }; // 環境類(開發組長) var Context = function(func, task) { typeof func === "function" && func(task); } Context(backend, "優化服務器緩存"); Context(frontend, "優化首頁加載速度"); Context(testend, "完成系統并發測試");
少了 Strategies 策略類的外層包裹,函數更加獨立,并不妨礙其調用。使用函數替代策略類方式,正是我們日常開發中經常用到的 “隱形” 策略模式。
適用場景多重條件語句判斷,執行對應的算法場景
表單校驗(validator)
優缺點
優點:
利用組合、委托、多態的技術和思想,避免多重條件選擇語句 if...else/switch...case;
復用性更高,算法函數可在系統其它地方使用;
支持設計模式 “開發-封閉原則“ ,算法封裝在獨立的 Strategy 中,易于維護和擴展;
策略模式使用 “組合和委托” 來讓 Context 擁有執行算法的能力,一種替換對象繼承的可行方案
缺點:
增加了許多策略類或對象(開發人員職能劃分明確,人員成本有所增加);
必須了解各個 Strategy 的不同點,違反 “最少知識原則”(組長手底下有對應的開發人員,才不用自己那么苦逼)
JavaScript設計模式整理系列正在更新中,敬請關注專欄 "前端進擊的巨人",獲取實時更新。
參考文章
《JavaScript 設計模式》
《JavaScript 設計模式與開發實踐》
《JavaScript 設計模式系統講解與應用》
本文首發Github,期待Star!
https://github.com/ZengLingYong/blog
作者:以樂之名
本文原創,有不當的地方歡迎指出。轉載請指明出處。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/104973.html
摘要:一個基于策略模式的程序至少由兩部分組成。優點策略模式利用組合委托和多態等技術和思想,可以有效地避免多重條件選擇語句。在策略模式中利用組合和委托來讓擁有執行算法的能力,這也是繼承的一種更輕便的替代方案。 一個基于策略模式的程序至少由兩部分組成。第一個部分是一組策略類,策略類封裝了具體的算法,并負責具體的計算過程。第二個部分是環境類Context,Context接受客戶的請求,隨后把請求委...
摘要:引言本文摘自設計模式與開發實踐在現實中,很多時候也有多種途徑到達同一個目的地。將不變的部分和變化的部分隔開是每個設計模式的主題,策略模式也不例外,策略模式的目的就是將算法的使用與算法的實現分離開來。一個基于策略模式的程序至少由兩部分組成。 引言 本文摘自《JavaScript設計模式與開發實踐》 在現實中,很多時候也有多種途徑到達同一個目的地。比如我們要去某個地方旅游,可以根據具體的實...
摘要:將不變的部分和變化的部分隔開是每個設計模式的主題,策略模式也不例外,策略模式的目的就是將算法的使用與算法的實現分離開來。 前言 本系列文章主要根據《JavaScript設計模式與開發實踐》整理而來,其中會加入了一些自己的思考。希望對大家有所幫助。 文章系列 js設計模式--單例模式 js設計模式--策略模式 js設計模式--代理模式 概念 策略模式的定義是:定義一系列的算法,把它們一個...
摘要:訂閱模式的一個典型的應用就是后面會寫一篇相關的讀書筆記。享元模式享元模式的核心思想是對象復用,減少對象數量,減少內存開銷。適配器模式對目標函數進行數據參數轉化,使其符合目標函數所需要的格式。 設計模式 單例模式 JS的單例模式有別于傳統面向對象語言的單例模式,js作為一門無類的語言。使用全局變量的模式來實現單例模式思想。js里面的單例又分為普通單例和惰性單例,惰性單例指的是只有這個實例...
摘要:個人前端文章整理從最開始萌生寫文章的想法,到著手開始寫,再到現在已經一年的時間了,由于工作比較忙,更新緩慢,后面還是會繼更新,現將已經寫好的文章整理一個目錄,方便更多的小伙伴去學習。 showImg(https://segmentfault.com/img/remote/1460000017490740?w=1920&h=1080); 個人前端文章整理 從最開始萌生寫文章的想法,到著手...
閱讀 1335·2021-10-27 14:14
閱讀 3585·2021-09-29 09:34
閱讀 2489·2019-08-30 15:44
閱讀 1734·2019-08-29 17:13
閱讀 2579·2019-08-29 13:07
閱讀 880·2019-08-26 18:26
閱讀 3353·2019-08-26 13:44
閱讀 3219·2019-08-26 13:37