「手摸手设计模式系列」策略模式与动态表单验证

时间 2019-11-05

标签设计模式系列策略动态表单验证栏目 HTML 繁體版

原文原文链接

策略模式 （Strategy Pattern）又称政策模式，其定义一系列的算法，把它们一个个封装起来，而且使它们能够互相替换。封装的策略算法通常是独立的，策略模式根据输入来调整采用哪一个算法。关键是策略的实现和使用分离。javascript

注意： 本文可能用到一些编码技巧好比 IIFE（Immediately Invoked Function Expression, 当即调用函数表达式），ES6 的语法 let/const、箭头函数、rest 参数，短路运算符等，若是还没接触过能够点击连接稍加学习 ~html

1. 你曾见过的策略模式

如今电子产品种类繁多，尺寸多种多样，有时候你会忍不住想拆开看看里面啥样（想一想小时候拆的玩具车还有遥控器😅），可是螺丝规格不少，螺丝刀尺寸也很多，若是每碰到一种规格就买一个螺丝刀，家里就得堆满螺丝刀了。因此如今人们都用多功能的螺丝刀套装，螺丝刀把只须要一个，碰到不一样规格的螺丝只要换螺丝刀头就好了，很方便，体积也变小不少。前端

再举个栗子，一辆车的轮胎有不少规格，在泥泞路段开的多的时候能够用泥地胎，在雪地开得多能够用雪地胎，高速公路上开的多的时候使用高性能轮胎，针对不一样使用场景更换不一样的轮胎便可，不需更换整个车。java

这些都是策略模式的实例，螺丝刀/车属于封装上下文，封装和使用不一样的螺丝刀头/轮胎，螺丝刀头/轮胎这里就至关于策略，能够根据需求不一样来更换不一样的使用策略。es6

在这些场景中，有如下特色：算法

螺丝刀头/轮胎（策略）之间相互独立，但又能够相互替换；
螺丝刀/车（封装上下文）能够根据须要的不一样选用不一样的策略；

2. 实例的代码实现

具体的例子咱们用编程上的例子来演示，比较好量化。编程

场景是这样的，某个电商网站但愿举办一个活动，经过打折促销来销售库存物品，有的商品满 100 减 30，有的商品满 200 减 80，有的商品直接8折出售（想起被双十一支配的恐惧），这样的逻辑交给咱们，咱们要怎样去实现呢。c#

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: 将文件大小（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){
  	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>
        <!-- 直接调用 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. 策略模式的优缺点

策略模式将算法的实现和使用拆分，这个特色带来了不少优势：

策略之间相互独立，但策略能够自由切换，这个策略模式的特色给策略模式带来不少灵活性，也提升了策略的复用率；
若是不采用策略模式，那么在选策略时通常会采用多重的条件判断，采用策略模式能够避免多重条件判断，增长可维护性；
可扩展性好，策略能够很方便的进行扩展；

策略模式的缺点：

策略相互独立，所以一些复杂的算法逻辑没法共享，形成一些资源浪费；
若是用户想采用什么策略，必须了解策略的实现，所以全部策略都需向外暴露，这是违背迪米特法则/最少知识原则的，也增长了用户对策略对象的使用成本。

6. 策略模式的适用场景

那么应该在什么场景下使用策略模式呢：

多个算法只在行为上稍有不一样的场景，这时可使用策略模式来动态选择算法；
算法须要自由切换的场景；
有时须要多重条件判断，那么可使用策略模式来规避多重条件判断的状况；

7. 其余相关模式

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

策略模式和模板方法模式的做用比较相似，可是结构和实现方式有点不同。

策略模式 让咱们在程序运行的时候动态地指定要使用的算法；
模板方法模式 是在子类定义的时候就已经肯定了使用的算法；

7.2 策略模式和享元模式

见享元模式中的介绍。

网上的帖子大多深浅不一，甚至有些先后矛盾，在下的文章都是学习过程当中的总结，若是发现错误，欢迎留言指出~

本文出自个人专栏 <JavaScript 设计模式精讲> 中的一篇，感兴趣的同窗能够点击连接看看更多文章～

PS：欢迎你们关注个人公众号【前端下午茶】，一块儿加油吧~

另外能够加入「前端下午茶交流群」微信群，长按识别下面二维码便可加我好友，备注加群，我拉你入群～

「手摸手设计模式系列」 策略模式与动态表单验证