「手摸手設計模式系列」 策略模式與動態表單驗證

策略模式 （Strategy Pattern）又稱政策模式，其定義一系列的算法，把它們一個個封裝起來，並且使它們可以互相替換。封裝的策略算法一般是獨立的，策略模式根據輸入來調整採用哪個算法。關鍵是策略的

實現和使用分離。

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

1. 你曾見過的策略模式

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

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

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

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

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

2. 實例的代碼實現

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

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

function priceCalculate(discountType, price) {
 if (discountType === 'minus100_30') { \t\t// 滿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. 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) {\t\t// 註冊新計算方式
 if (DiscountMap[discountType]) return
 DiscountMap[discountType] = fn
 }
 }
})()
PriceCalculate.priceClac('minus100_30', 270)\t// 輸出: 210
PriceCalculate.addStrategy('minus150_40', function(price) {
 return price - Math.floor(price / 150) * 40
})
PriceCalculate.priceClac('minus150_40', 270)\t// 輸出: 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) { 
 \treturn price - Math.floor(price / 100) * 30
}
context('minus100_30', 270)\t\t\t// 輸出: 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){
 \tStrategyMap[type](row[rowKey])
 }
}
export default strategyContext
複製代碼

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

<template>
 <el-table>
 <el-table-column>
 <el-table-column>
 
 <el-table-column> :formatter='strategyContext("bitToKB", "sizeKb")'>
 /<el-table-column>
 <el-table-column> :formatter='strategyContext("bitToMB", "sizeMb")'>
 /<el-table-column>
 /<el-table>
/<template>
<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> label-width="100px"
 class="demo-ruleForm"
 :rules="rules"
 :model="ruleForm">
 
 <el-form-item>
 <el-input>
 /<el-form-item>
 
 <el-form-item>
 <el-input>
 /<el-form-item>
 
 <el-form-item>
 <el-input>
 /<el-form-item>
 /<el-form>
/<template>
複製代碼

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

代碼實例可以參看 codesandbox - 策略模式表單驗證實戰

運行結果：

5. 策略模式的優缺點

策略模式將算法的實現和使用拆分，這個特點帶來了很多優點：

1. 策略之間相互獨立，但策略可以自由切換，這個策略模式的特點給策略模式帶來很多靈活性，也提高了策略的複用率；
2. 如果不採用策略模式，那麼在選策略時一般會採用多重的條件判斷，採用策略模式可以避免多重條件判斷，增加可維護性；
3. 可擴展性好，策略可以很方便的進行擴展；

策略模式的缺點：

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

6. 策略模式的適用場景

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

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

7. 其他相關模式

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

策略模式和模板方法模式的作用比較類似，但是結構和實現方式有點不一樣。

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

7.2 策略模式和享元模式

見享元模式中的介紹。