JavaScript 設計模式系列 - 策略模式與動態表單驗證

時間  2019-11-05
標籤 javascript 設計 模式 系列 策略 動態 表單 驗證 欄目 JavaScript 简体版
原文   原文鏈接

策略模式 （Strategy Pattern）又稱政策模式，其定義一系列的算法，把它們一個個封裝起來，而且使它們能夠互相替換。封裝的策略算法通常是獨立的，策略模式根據輸入來調整採用哪一個算法。關鍵是策略的實現和使用分離。javascript

注意： 本文可能用到一些編碼技巧好比 IIFE（Immediately Invoked Function Expression, 當即調用函數表達式），ES6 的語法 let/const、 箭頭函數、 rest 參數， 短路運算符 等，若是還沒接觸過能夠點擊連接稍加學習 ~

1. 你曾見過的策略模式

如今電子產品種類繁多，尺寸多種多樣，有時候你會忍不住想拆開看看裏面啥樣（想一想小時候拆的玩具車還有遙控器），可是螺絲規格不少，螺絲刀尺寸也很多，若是每碰到一種規格就買一個螺絲刀，家裏就得堆滿螺絲刀了。因此如今人們都用多功能的螺絲刀套裝，螺絲刀把只須要一個，碰到不一樣規格的螺絲只要換螺絲刀頭就好了，很方便，體積也變小不少。html

再舉個栗子，一輛車的輪胎有不少規格，在泥濘路段開的多的時候能夠用泥地胎，在雪地開得多能夠用雪地胎，高速公路上開的多的時候使用高性能輪胎，針對不一樣使用場景更換不一樣的輪胎便可，不需更換整個車。前端

這些都是策略模式的實例，螺絲刀/車屬於封裝上下文，封裝和使用不一樣的螺絲刀頭/輪胎，螺絲刀頭/輪胎這裏就至關於策略，能夠根據需求不一樣來更換不一樣的使用策略。java

在這些場景中，有如下特色：es6

  1. 螺絲刀頭/輪胎（策略）之間相互獨立，但又能夠相互替換；
  2. 螺絲刀/車（封裝上下文）能夠根據須要的不一樣選用不一樣的策略；

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 就知足了需求，可是這樣的作法的缺點也很明顯：c#

  1. priceCalculate 函數隨着折扣類型的增多，if-else 判斷語句會變得愈來愈臃腫；
  2. 若是增長了新的折扣類型或者折扣類型的算法有所改變，那麼須要更改 priceCalculate 函數的實現，這是違反開放-封閉原則的；
  3. 可複用性差，若是在其餘的地方也有相似這樣的算法，但規則不同，上述代碼不能複用；

咱們能夠改造一下，將計算折扣的算法部分提取出來保存爲一個對象，折扣的類型做爲 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），封裝上下文能夠根據須要選擇不一樣的策略。

主要有下面幾個概念：

  1. Context ：封裝上下文，根據須要調用須要的策略，屏蔽外界對策略的直接調用，只對外提供一個接口，根據須要調用對應的策略；
  2. Strategy ：策略，含有具體的算法，其方法的外觀相同，所以能夠互相代替；
  3. 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: 將文件大小（bit）轉化爲 KB */
    bitToKB: val => {
        const num = Number(val)
        return isNaN(num) ? val : (num / 1024).toFixed(0) + 'KB'
    },
    /* Strategy 2: 將文件大小（bit）轉化爲 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

那麼在組件中咱們能夠直接：

<template>
    <el-table :data="tableData">
        <el-table-column prop="date" label="日期"></el-table-column>
        <el-table-column prop="name" label="文件名"></el-table-column>
        <!-- 直接調用 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 - 策略模式實戰

運行結果以下圖：

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 = /^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 中增長一個柯里化方法，用來生成表單驗證函數：

// 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 文件中提取出來的通用驗證規則的方法名，第二個參數是報錯的話表單驗證的提示信息。

<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="手機號" 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', '手機號由以1開頭的11位數字組成'),
                        trigger: 'blur'
                    }],
                    email: [{
                        validator: Utils.formValidateGene('validateEmail', '不是正確的郵箱格式'),
                        trigger: 'blur'
                    }]
                }
            }
        }
    }
</script>

能夠看見在使用的時候很是方便，把表單驗證方法提取出來做爲策略，使用柯里化方法動態選擇表單驗證方法，從而對策略靈活運用，大大加快開發效率。

代碼實例能夠參看 codesandbox - 策略模式表單驗證明戰

運行結果：

5. 策略模式的優缺點

策略模式將算法的實現和使用拆分，這個特色帶來了不少優勢：

  1. 策略之間相互獨立，但策略能夠自由切換，這個策略模式的特色給策略模式帶來不少靈活性，也提升了策略的複用率；
  2. 若是不採用策略模式，那麼在選策略時通常會採用多重的條件判斷，採用策略模式能夠避免多重條件判斷，增長可維護性；
  3. 可擴展性好，策略能夠很方便的進行擴展；

策略模式的缺點：

  1. 策略相互獨立，所以一些複雜的算法邏輯沒法共享，形成一些資源浪費；
  2. 若是用戶想採用什麼策略，必須瞭解策略的實現，所以全部策略都需向外暴露，這是違背迪米特法則/最少知識原則的，也增長了用戶對策略對象的使用成本。

6. 策略模式的適用場景

那麼應該在什麼場景下使用策略模式呢：

  1. 多個算法只在行爲上稍有不一樣的場景，這時可使用策略模式來動態選擇算法；
  2. 算法須要自由切換的場景；
  3. 有時須要多重條件判斷，那麼可使用策略模式來規避多重條件判斷的狀況；

7. 其餘相關模式

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

策略模式和模板方法模式的做用比較相似，可是結構和實現方式有點不同。

  1. 策略模式 讓咱們在程序運行的時候動態地指定要使用的算法；
  2. 模板方法模式 是在子類定義的時候就已經肯定了使用的算法；

7.2 策略模式和享元模式

見享元模式中的介紹。

網上的帖子大多深淺不一，甚至有些先後矛盾，在下的文章都是學習過程當中的總結，若是發現錯誤，歡迎留言指出~

本文出自個人專欄 <JavaScript 設計模式精講> 中的一篇，感興趣的同窗能夠點擊連接看看更多文章～

PS：歡迎你們關注個人公衆號【前端下午茶】，一塊兒加油吧~

另外能夠加入「前端下午茶交流羣」微信羣，長按識別下面二維碼便可加我好友，備註加羣，我拉你入羣～

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程