摘要:策略模式又稱政策模式,其定義一系列的算法,把它們一個個封裝起來,并且使它們可以互相替換。的表單具有表單驗證功能,用來校驗用戶輸入的表單內容。實際需求中表單驗證項一般會比較復雜,所以需要給每個表單項增加自定義校驗方法。
策略模式 (Strategy Pattern)又稱政策模式,其定義一系列的算法,把它們一個個封裝起來,并且使它們可以互相替換。封裝的策略算法一般是獨立的,策略模式根據輸入來調整采用哪個算法。關鍵是策略的實現和使用分離。
注意: 本文可能用到一些編碼技巧比如 IIFE(Immediately Invoked Function Expression, 立即調用函數表達式),ES6 的語法 let/const、箭頭函數、rest 參數,短路運算符 等,如果還沒接觸過可以點擊鏈接稍加學習 ~1. 你曾見過的策略模式
現在電子產品種類繁多,尺寸多種多樣,有時候你會忍不住想拆開看看里面啥樣(想想小時候拆的玩具車還有遙控器),但是螺絲規格很多,螺絲刀尺寸也不少,如果每碰到一種規格就買一個螺絲刀,家里就得堆滿螺絲刀了。所以現在人們都用多功能的螺絲刀套裝,螺絲刀把只需要一個,碰到不同規格的螺絲只要換螺絲刀頭就行了,很方便,體積也變小很多。
再舉個栗子,一輛車的輪胎有很多規格,在泥濘路段開的多的時候可以用泥地胎,在雪地開得多可以用雪地胎,高速公路上開的多的時候使用高性能輪胎,針對不同使用場景更換不同的輪胎即可,不需更換整個車。
這些都是策略模式的實例,螺絲刀/車屬于封裝上下文,封裝和使用不同的螺絲刀頭/輪胎,螺絲刀頭/輪胎這里就相當于策略,可以根據需求不同來更換不同的使用策略。
在這些場景中,有以下特點:
螺絲刀頭/輪胎(策略)之間相互獨立,但又可以相互替換;
螺絲刀/車(封裝上下文)可以根據需要的不同選用不同的策略;
2. 實例的代碼實現具體的例子我們用編程上的例子來演示,比較好量化。
場景是這樣的,某個電商網站希望舉辦一個活動,通過打折促銷來銷售庫存物品,有的商品滿 100 減 30,有的商品滿 200 減 80,有的商品直接8折出售(想起被雙十一支配的恐懼),這樣的邏輯交給我們,我們要怎樣去實現呢。
function priceCalculate(discountType, price) { if (discountType === "minus100_30") { // 滿100減30 return price - Math.floor(price / 100) * 30 } else if (discountType === "minus200_80") { // 滿200減80 return price - Math.floor(price / 200) * 80 } else if (discountType === "percent80") { // 8折 return price * 0.8 } } priceCalculate("minus100_30", 270) // 輸出: 210 priceCalculate("percent80", 250) // 輸出: 200
通過判斷輸入的折扣類型來計算計算商品總價的方式,幾個 if-else 就滿足了需求,但是這樣的做法的缺點也很明顯:
priceCalculate 函數隨著折扣類型的增多,if-else 判斷語句會變得越來越臃腫;
如果增加了新的折扣類型或者折扣類型的算法有所改變,那么需要更改 priceCalculate 函數的實現,這是違反開放-封閉原則的;
可復用性差,如果在其他的地方也有類似這樣的算法,但規則不一樣,上述代碼不能復用;
我們可以改造一下,將計算折扣的算法部分提取出來保存為一個對象,折扣的類型作為 key,這樣索引的時候通過對象的鍵值索引調用具體的算法:
const DiscountMap = { minus100_30: function(price) { return price - Math.floor(price / 100) * 30 }, minus200_80: function(price) { return price - Math.floor(price / 200) * 80 }, percent80: function(price) { return price * 0.8 } } /* 計算總售價*/ function priceCalculate(discountType, price) { return DiscountMap[discountType] && DiscountMap[discountType](price) } priceCalculate("minus100_30", 270) priceCalculate("percent80", 250) // 輸出: 210 // 輸出: 200
這樣算法的實現和算法的使用就被分開了,想添加新的算法也變得十分簡單:
DiscountMap.minus150_40 = function(price) { return price - Math.floor(price / 150) * 40 }
如果你希望計算算法隱藏起來,那么可以借助 IIFE 使用閉包的方式,這時需要添加增加策略的入口,以方便擴展:
const PriceCalculate = (function() { /* 售價計算方式 */ const DiscountMap = { minus100_30: function(price) { // 滿100減30 return price - Math.floor(price / 100) * 30 }, minus200_80: function(price) { // 滿200減80 return price - Math.floor(price / 200) * 80 }, percent80: function(price) { // 8折 return price * 0.8 } } return { priceClac: function(discountType, price) { return DiscountMap[discountType] && DiscountMap[discountType](price) }, addStrategy: function(discountType, fn) { // 注冊新計算方式 if (DiscountMap[discountType]) return DiscountMap[discountType] = fn } } })() PriceCalculate.priceClac("minus100_30", 270) // 輸出: 210 PriceCalculate.addStrategy("minus150_40", function(price) { return price - Math.floor(price / 150) * 40 }) PriceCalculate.priceClac("minus150_40", 270) // 輸出: 230
這樣算法就被隱藏起來,并且預留了增加策略的入口,便于擴展。
3. 策略模式的通用實現根據上面的例子提煉一下策略模式,折扣計算方式可以被認為是策略(Strategy),這些策略之間可以相互替代,而具體折扣的計算過程可以被認為是封裝上下文(Context),封裝上下文可以根據需要選擇不同的策略。
主要有下面幾個概念:
Context :封裝上下文,根據需要調用需要的策略,屏蔽外界對策略的直接調用,只對外提供一個接口,根據需要調用對應的策略;
Strategy :策略,含有具體的算法,其方法的外觀相同,因此可以互相代替;
StrategyMap :所有策略的合集,供封裝上下文調用;
結構圖如下:
下面使用通用化的方法實現一下。
const StrategyMap = {} function context(type, ...rest) { return StrategyMap[type] && StrategyMap[type](...rest) } StrategyMap.minus100_30 = function(price) { return price - Math.floor(price / 100) * 30 } context("minus100_30", 270) // 輸出: 210
通用實現看起來似乎比較簡單,這里分享一下項目實戰。
4. 實戰中的策略模式 4.1 表格 formatter這里舉一個 Vue + ElementUI 項目中用到的例子,其他框架的項目原理也類似,和大家分享一下。
Element 的表格控件的 Column 接受一個 formatter 參數,用來格式化內容,其類型為函數,并且還可以接受幾個特定參數,像這樣: Function(row, column, cellValue, index)。
以文件大小轉化為例,后端經常會直接傳 bit 單位的文件大小,那么前端需要根據后端的數據,根據需求轉化為自己需要的單位的文件大小,比如 KB/MB。
首先實現文件計算的算法:
export const StrategyMap = { /* Strategy 1: 將文件大?。╞it)轉化為 KB */ bitToKB: val => { const num = Number(val) return isNaN(num) ? val : (num / 1024).toFixed(0) + "KB" }, /* Strategy 2: 將文件大?。╞it)轉化為 MB */ bitToMB: val => { const num = Number(val) return isNaN(num) ? val : (num / 1024 / 1024).toFixed(1) + "MB" } } /* Context: 生成el表單 formatter */ const strategyContext = function(type, rowKey){ return function(row, column, cellValue, index){ StrategyMap[type](row[rowKey]) } } export default strategyContext
那么在組件中我們可以直接:
代碼實例可以參看 codepen - 策略模式實戰
運行結果如下圖:
4.2 表單驗證除了表格中的 formatter 之外,策略模式也經常用在表單驗證的場景,這里舉一個 Vue + ElementUI 項目的例子,其他框架同理。
ElementUI 的 Form 表單 具有表單驗證功能,用來校驗用戶輸入的表單內容。實際需求中表單驗證項一般會比較復雜,所以需要給每個表單項增加 validator 自定義校驗方法。
我們可以像官網示例一樣把表單驗證都寫在組件的狀態 data 函數中,但是這樣就不好復用使用頻率比較高的表單驗證方法了,這時我們可以結合策略模式和函數柯里化的知識來重構一下。首先我們在項目的工具模塊(一般是 utils 文件夾)實現通用的表單驗證方法:
// src/utils/validates.js /* 姓名校驗 由2-10位漢字組成 */ export function validateUsername(str) { const reg = /^[u4e00-u9fa5]{2,10}$/ return reg.test(str) } /* 手機號校驗 由以1開頭的11位數字組成 */ export function validateMobile(str) { const reg = /^1d{10}$/ return reg.test(str) } /* 郵箱校驗 */ export function validateEmail(str) { const reg = /^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(.[a-zA-Z0-9_-]+)+$/ return reg.test(str) }
然后在 utils/index.js 中增加一個柯里化方法,用來生成表單驗證函數:
// src/utils/index.js import * as Validates from "./validates.js" /* 生成表格自定義校驗函數 */ export const formValidateGene = (key, msg) => (rule, value, cb) => { if (Validates[key](value)) { cb() } else { cb(new Error(msg)) } }
上面的 formValidateGene 函數接受兩個參數,第一個是驗證規則,也就是 src/utils/validates.js 文件中提取出來的通用驗證規則的方法名,第二個參數是報錯的話表單驗證的提示信息。
可以看見在使用的時候非常方便,把表單驗證方法提取出來作為策略,使用柯里化方法動態選擇表單驗證方法,從而對策略靈活運用,大大加快開發效率。
代碼實例可以參看 codesandbox - 策略模式表單驗證實戰
運行結果:
5. 策略模式的優缺點策略模式將算法的實現和使用拆分,這個特點帶來了很多優點:
策略之間相互獨立,但策略可以自由切換,這個策略模式的特點給策略模式帶來很多靈活性,也提高了策略的復用率;
如果不采用策略模式,那么在選策略時一般會采用多重的條件判斷,采用策略模式可以避免多重條件判斷,增加可維護性;
可擴展性好,策略可以很方便的進行擴展;
策略模式的缺點:
策略相互獨立,因此一些復雜的算法邏輯無法共享,造成一些資源浪費;
如果用戶想采用什么策略,必須了解策略的實現,因此所有策略都需向外暴露,這是違背迪米特法則/最少知識原則的,也增加了用戶對策略對象的使用成本。
6. 策略模式的適用場景那么應該在什么場景下使用策略模式呢:
多個算法只在行為上稍有不同的場景,這時可以使用策略模式來動態選擇算法;
算法需要自由切換的場景;
有時需要多重條件判斷,那么可以使用策略模式來規避多重條件判斷的情況;
7. 其他相關模式 7.1 策略模式和模板方法模式策略模式和模板方法模式的作用比較類似,但是結構和實現方式有點不一樣。
策略模式 讓我們在程序運行的時候動態地指定要使用的算法;
模板方法模式 是在子類定義的時候就已經確定了使用的算法;
7.2 策略模式和享元模式見享元模式中的介紹。
網上的帖子大多深淺不一,甚至有些前后矛盾,在下的文章都是學習過程中的總結,如果發現錯誤,歡迎留言指出~
本文出自我的專欄
PS:歡迎大家關注我的公眾號【前端下午茶】,一起加油吧~
另外可以加入「前端下午茶交流群」微信群,長按識別下面二維碼即可加我好友,備注加群,我拉你入群~
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/110058.html
摘要:策略模式可以避免代碼中的多重判斷條件。策略模式在程序中或多或少的增加了策略類。此文僅記錄本人閱讀設計模式與開發實踐這個本時的感受,感謝作者曾探寫出這么好的一本書。設計模式中很重要的一點就是將不變和變分離出來。參考設計模式與開發實踐曾探 策略模式的定義是:定義一系列的算法,把它們一個個封裝起來,并且是它們可以相互替換。 策略模式可以避免代碼中的多重判斷條件。 策略模式很好的體現了開放-...
摘要:單體模式有以下優點用來劃分命名空間,減少全局變量數量。通常我們使用操作符創建單體模式的三種選擇,讓構造函數總返回最初的對象使用全局對象來存儲該實例不推薦,容易全局污染。實現該工廠模式并不困難,主要是要找到能夠穿件所需類型對象的構造函數。 介紹 最近開始給自己每周訂個學習任務,學習結果反饋為一篇文章的輸出,做好學習記錄。 這一周(02.25-03.03)我定的目標是《JavaScri...
原文收錄在我的 GitHub博客 (https://github.com/jawil/blog) ,喜歡的可以關注最新動態,大家一起多交流學習,共同進步,以學習者的身份寫博客,記錄點滴。 在一個Web項目中,注冊,登錄,修改用戶信息,下訂單等功能的實現都離不開提交表單。這篇文章就闡述了如何編寫相對看著舒服的表單驗證代碼。 假設我們正在編寫一個注冊的頁面,在點擊注冊按鈕之前,有如下幾條校驗邏輯。 ...
原文收錄在我的 GitHub博客 (https://github.com/jawil/blog) ,喜歡的可以關注最新動態,大家一起多交流學習,共同進步,以學習者的身份寫博客,記錄點滴。 在一個Web項目中,注冊,登錄,修改用戶信息,下訂單等功能的實現都離不開提交表單。這篇文章就闡述了如何編寫相對看著舒服的表單驗證代碼。 假設我們正在編寫一個注冊的頁面,在點擊注冊按鈕之前,有如下幾條校驗邏輯。 ...
閱讀 3105·2021-11-18 10:02
閱讀 2617·2021-10-13 09:47
閱讀 3033·2021-09-22 15:07
閱讀 791·2019-08-30 15:43
閱讀 1809·2019-08-30 10:59
閱讀 1684·2019-08-29 15:34
閱讀 1702·2019-08-29 15:06
閱讀 438·2019-08-29 13:28