Vue中怎么利用策略模式實現(xiàn)動態(tài)表單驗證

Vue中怎么利用策略模式實現(xiàn)動態(tài)表單驗證，相信很多沒有經(jīng)驗的人對此束手無策，為此本文總結(jié)了問題出現(xiàn)的原因和解決方法，通過這篇文章希望你能解決這個問題。

1.  你曾見過的策略模式

現(xiàn)在電子產(chǎn)品種類繁多，尺寸多種多樣，有時候你會忍不住想拆開看看里面啥樣(想想小時候拆的玩具車還有遙控器)，但是螺絲規(guī)格很多，螺絲刀尺寸也不少，如果每碰到一種規(guī)格就買一個螺絲刀，家里就得堆滿螺絲刀了。所以現(xiàn)在人們都用多功能的螺絲刀套裝，螺絲刀把只需要一個，碰到不同規(guī)格的螺絲只要換螺絲刀頭就行了，很方便，體積也變小很多。

再舉個栗子，一輛車的輪胎有很多規(guī)格，在泥濘路段開的多的時候可以用泥地胎，在雪地開得多可以用雪地胎，高速公路上開的多的時候使用高性能輪胎，針對不同使用場景更換不同的輪胎即可，不需更換整個車。

這些都是策略模式的實例，螺絲刀/車屬于封裝上下文，封裝和使用不同的螺絲刀頭/輪胎，螺絲刀頭/輪胎這里就相當(dāng)于策略，可以根據(jù)需求不同來更換不同的使用策略。

在這些場景中，有以下特點：

螺絲刀頭/輪胎(策略)之間相互獨立，但又可以相互替換;

螺絲刀/車(封裝上下文)可以根據(jù)需要的不同選用不同的策略;

2. 實例的代碼實現(xiàn)

具體的例子我們用編程上的例子來演示，比較好量化。

場景是這樣的，某個電商網(wǎng)站希望舉辦一個活動，通過打折促銷來銷售庫存物品，有的商品滿 100 減 30，有的商品滿 200 減  80，有的商品直接8折出售(想起被雙十一支配的恐懼)，這樣的邏輯交給我們，我們要怎樣去實現(xiàn)呢。

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 就滿足了需求，但是這樣的做法的缺點也很明顯：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. priceCalculate 函數(shù)隨著折扣類型的增多，if-else 判斷語句會變得越來越臃腫;

3. 如果增加了新的折扣類型或者折扣類型的算法有所改變，那么需要更改 priceCalculate函數(shù)的實現(xiàn)，這是違反開放-封閉原則的;

4. 可復(fù)用性差，如果在其他的地方也有類似這樣的算法，但規(guī)則不一樣，上述代碼不能復(fù)用;

我們可以改造一下，將計算折扣的算法部分提取出來保存為一個對象，折扣的類型作為 key，這樣索引的時候通過對象的鍵值索引調(diào)用具體的算法：

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

這樣算法的實現(xiàn)和算法的使用就被分開了，想添加新的算法也變得十分簡單：

DiscountMap.minus150_40 = function(price) {     return price - Math.floor(price / 150) * 40 }

如果你希望計算算法隱藏起來，那么可以借助 IIFE 使用閉包的方式，這時需要添加增加策略的入口，以方便擴(kuò)展：

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

這樣算法就被隱藏起來，并且預(yù)留了增加策略的入口，便于擴(kuò)展。

3.  策略模式的通用實現(xiàn)

根據(jù)上面的例子提煉一下策略模式，折扣計算方式可以被認(rèn)為是策略(Strategy)，這些策略之間可以相互替代，而具體折扣的計算過程可以被認(rèn)為是封裝上下文(Context)，封裝上下文可以根據(jù)需要選擇不同的策略。

主要有下面幾個概念：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. Context ：封裝上下文，根據(jù)需要調(diào)用需要的策略，屏蔽外界對策略的直接調(diào)用，只對外提供一個接口，根據(jù)需要調(diào)用對應(yīng)的策略;

3. Strategy ：策略，含有具體的算法，其方法的外觀相同，因此可以互相代替;

4. StrategyMap ：所有策略的合集，供封裝上下文調(diào)用;

結(jié)構(gòu)圖如下：

策略模式

下面使用通用化的方法實現(xiàn)一下。

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

通用實現(xiàn)看起來似乎比較簡單，這里分享一下項目實戰(zhàn)。

4. 實戰(zhàn)中的策略模式

4.1 表格 formatter

這里舉一個 Vue + ElementUI 項目中用到的例子，其他框架的項目原理也類似，和大家分享一下。

Element 的表格控件的 Column 接受一個 formatter  參數(shù)，用來格式化內(nèi)容，其類型為函數(shù)，并且還可以接受幾個特定參數(shù)，像這樣：Function(row, column, cellValue, index)。

以文件大小轉(zhuǎn)化為例，后端經(jīng)常會直接傳 bit 單位的文件大小，那么前端需要根據(jù)后端的數(shù)據(jù)，根據(jù)需求轉(zhuǎn)化為自己需要的單位的文件大小，比如  KB/MB。

首先實現(xiàn)文件計算的算法：

export const StrategyMap = {     /* Strategy 1: 將文件大?。╞it）轉(zhuǎn)化為 KB */     bitToKB: val => {         const num = Number(val)         return isNaN(num) ? val : (num / 1024).toFixed(0) + 'KB'     },     /* Strategy 2: 將文件大?。╞it）轉(zhuǎn)化為 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){     return StrategyMap[type](row[rowKey])   } }  export default strategyContext

那么在組件中我們可以直接：

<template>     <el-table :data="tableData">         <el-table-column prop="date" label="日期"></el-table-column>         <el-table-column prop="name" label="文件名"></el-table-column>         <!-- 直接調(diào)用 strategyContext -->         <el-table-column prop="sizeKb" label="文件大小(KB)"                          :formatter='strategyContext("bitToKB", "sizeKb")'>         </el-table-column>         <el-table-column prop="sizeMb" label="附件大小(MB)"                          :formatter='strategyContext("bitToMB", "sizeMb")'>         </el-table-column>     </el-table> </template>  <script type='text/javascript'>     import strategyContext from './strategyContext.js'          export default {         name: 'ElTableDemo',         data() {             return {                 strategyContext,                 tableData: [                     { date: '2019-05-02', name: '文件1', sizeKb: 1234, sizeMb: 1234426 },                     { date: '2019-05-04', name: '文件2', sizeKb: 4213, sizeMb: 8636152 }]             }         }     } </script>  <style scoped></style>

代碼實例可以參看 codepen - 策略模式實戰(zhàn)

運(yùn)行結(jié)果如下圖：

4.2 表單驗證

除了表格中的 formatter 之外，策略模式也經(jīng)常用在表單驗證的場景，這里舉一個 Vue + ElementUI 項目的例子，其他框架同理。

ElementUI 的 Form 表單 具有表單驗證功能，用來校驗用戶輸入的表單內(nèi)容。實際需求中表單驗證項一般會比較復(fù)雜，所以需要給每個表單項增加  validator 自定義校驗方法。

我們可以像官網(wǎng)示例一樣把表單驗證都寫在組件的狀態(tài) data  函數(shù)中，但是這樣就不好復(fù)用使用頻率比較高的表單驗證方法了，這時我們可以結(jié)合策略模式和函數(shù)柯里化的知識來重構(gòu)一下。首先我們在項目的工具模塊(一般是 utils  文件夾)實現(xiàn)通用的表單驗證方法：

// src/utils/validates.js  /* 姓名校驗 由2-10位漢字組成 */ export function validateUsername(str) {     const reg = /^[\u4e00-\u9fa5]{2,10}$/     return reg.test(str) }  /* 手機(jī)號校驗 由以1開頭的11位數(shù)字組成  */ export function validateMobile(str) {     const reg = /^1\d{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 中增加一個柯里化方法，用來生成表單驗證函數(shù)：

// src/utils/index.js  import * as Validates from './validates.js'  /* 生成表格自定義校驗函數(shù) */ export const formValidateGene = (key, msg) => (rule, value, cb) => {     if (Validates[key](value)) {         cb()     } else {         cb(new Error(msg))     } }

上面的 formValidateGene 函數(shù)接受兩個參數(shù)，第一個是驗證規(guī)則，也就是 src/utils/validates.js  文件中提取出來的通用驗證規(guī)則的方法名，第二個參數(shù)是報錯的話表單驗證的提示信息。

<template>     <el-form ref="ruleForm"              label-width="100px"              class="demo-ruleForm"              :rules="rules"              :model="ruleForm">                  <el-form-item label="用戶名" prop="username">             <el-input v-model="ruleForm.username"></el-input>         </el-form-item>                  <el-form-item label="手機(jī)號" prop="mobile">             <el-input v-model="ruleForm.mobile"></el-input>         </el-form-item>                  <el-form-item label="郵箱" prop="email">             <el-input v-model="ruleForm.email"></el-input>         </el-form-item>     </el-form> </template>  <script type='text/javascript'>     import * as Utils from '../utils'          export default {         name: 'ElTableDemo',         data() {             return {                 ruleForm: { pass: '', checkPass: '', age: '' },                 rules: {                     username: [{                         validator: Utils.formValidateGene('validateUsername', '姓名由2-10位漢字組成'),                         trigger: 'blur'                     }],                     mobile: [{                         validator: Utils.formValidateGene('validateMobile', '手機(jī)號由以1開頭的11位數(shù)字組成'),                         trigger: 'blur'                     }],                     email: [{                         validator: Utils.formValidateGene('validateEmail', '不是正確的郵箱格式'),                         trigger: 'blur'                     }]                 }             }         }     } </script>

可以看見在使用的時候非常方便，把表單驗證方法提取出來作為策略，使用柯里化方法動態(tài)選擇表單驗證方法，從而對策略靈活運(yùn)用，大大加快開發(fā)效率。

代碼實例可以參看 codesandbox - 策略模式表單驗證實戰(zhàn)

運(yùn)行結(jié)果：

5. 策略模式的優(yōu)缺點

策略模式將算法的實現(xiàn)和使用拆分，這個特點帶來了很多優(yōu)點：

策略之間相互獨立，但策略可以自由切換，這個策略模式的特點給策略模式帶來很多靈活性，也提高了策略的復(fù)用率;

如果不采用策略模式，那么在選策略時一般會采用多重的條件判斷，采用策略模式可以避免多重條件判斷，增加可維護(hù)性;

可擴(kuò)展性好，策略可以很方便的進(jìn)行擴(kuò)展;

策略模式的缺點：

• 策略相互獨立，因此一些復(fù)雜的算法邏輯無法共享，造成一些資源浪費;

• 如果用戶想采用什么策略，必須了解策略的實現(xiàn)，因此所有策略都需向外暴露，這是違背迪米特法則/最少知識原則的，也增加了用戶對策略對象的使用成本。

6. 策略模式的適用場景

那么應(yīng)該在什么場景下使用策略模式呢：

• 多個算法只在行為上稍有不同的場景，這時可以使用策略模式來動態(tài)選擇算法;

• 算法需要自由切換的場景;

• 有時需要多重條件判斷，那么可以使用策略模式來規(guī)避多重條件判斷的情況;

7. 其他相關(guān)模式

7.1 策略模式和模板方法模式

策略模式和模板方法模式的作用比較類似，但是結(jié)構(gòu)和實現(xiàn)方式有點不一樣。

• 策略模式 讓我們在程序運(yùn)行的時候動態(tài)地指定要使用的算法;

• 模板方法模式 是在子類定義的時候就已經(jīng)確定了使用的算法;

看完上述內(nèi)容，你們掌握Vue中怎么利用策略模式實現(xiàn)動態(tài)表單驗證的方法了嗎？如果還想學(xué)到更多技能或想了解更多相關(guān)內(nèi)容，歡迎關(guān)注億速云行業(yè)資訊頻道，感謝各位的閱讀！