Javascript-设计模式_策略模式

前言

假设我们现在需要定义一个手机的基本能力，call和message，分别表示通话和短信能力，来给客户演示不同手机的能力区别，以达到推销赞助商手机的功能

但是随着智能手机的发展，手机的通话和短信的能力都已得到很大程度的增强

比方说，我们有两款手机，一个是10年前的老牌 Nokia,只能发些简单的文本信息，打电话什么的也没有视频的能力。但是新版的小米手机，却能安装很多APP，比方说QQ、微信，不仅可以进行视频通话，还可以发送富文本信息

那么问题来了，如何定义一个模型，能够将手机通话和短信的能力抽象出来，以满足今天我们需要用Nokia手机演示功能，明天我们要用小米手机演示功能，后天我们要.....

这种时候，我们可以考虑很多种方案来设计，但是一个优秀的模型设计应该是要尽可能的符合设计原则的，这就是接下来要分析的策略模式

 

 

策略模式

定义

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

 

核心

将算法的使用和算法的实现分离开来

一个基于策略模式的程序至少由两部分组成：

• 第一个部分是一组策略类，策略类封装了具体的算法，并负责具体的计算过程

• 第二个部分是环境类Context，Context接受客户的请求，随后把请求委托给某一个策略类。要做到这点，说明Context 中要维持对某个策略对象的引用

 

相关设计原则

• 多用组合，少用继承

• 针对接口编程，而不是对实现编程

• 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混合在一起

 

代码示例

场景是这样的，某个电商网站希望举办一个活动，通过打折促销来销售库存物品，有的商品满 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 就满足了需求，但是这样的做法的缺点也很明显

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

这样算法的实现和算法的使用就被分开了，想添加新的算法也变得十分简单

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

这样算法就被隐藏起来，并且预留了增加策略的入口，便于扩展

 

策略模式的通用实现

根据上面的例子提炼一下策略模式，折扣计算方式可以被认为是策略（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

 

策略模式-表单验证

ElementUI 的 Form 表单具有表单验证功能，用来校验用户输入的表单内容。实际需求中表单验证项一般会比较复杂，所以需要给每个表单项增加 validator 自定义校验方法

我们可以像官网示例一样把表单验证都写在组件的状态 data 函数中，但是这样就不好复用使用频率比较高的表单验证方法了，这时我们可以结合策略模式和函数柯里化的知识来重构一下。首先我们在项目的工具模块（一般是 utils 文件夹）实现通用的表单验证方法

/* 姓名校验 由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)
}

然后增加一个柯里化方法，用来生成表单验证函数

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 函数接受两个参数，第一个是验证规则，也就是前面提取出来的通用验证规则的方法名，第二个参数是报错的话表单验证的提示信息

<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>

可以看见在使用的时候非常方便，把表单验证方法提取出来作为策略，使用柯里化方法动态选择表单验证方法，从而对策略灵活运用，大大加快开发效率

小结

• 策略模式利用委托/组合/多态等思想，可以有效避免多重条件选择语句

• 策略模式对开放-封闭原则做了完美的诠释，算法独立封装在strategy类中，使之利于切换，易于理解和扩展

但是，策略模式必须向使用者公开实现细节，是违反迪米特原则的

迪米特法则（Law of Demeter）又叫作最少知识原则（Least Knowledge Principle 简写LKP），就是说一个对象应当对其他对象有尽可能少的了解,不和陌生人说话。英文简写为: LoD.

在JavaScript这种"函数作为一等对象"的语言中，策略模式是隐形的。策略类就是函数。我们可以用高阶函数来封装不同的行为

 

策略模式的优缺点

• 优点

  利用组合、委托、多态等技术和思想，避免多重条件选择语句

  易于切换、理解、扩展

  可以复用

  利用组合，委托和多态等技术思想，可以避免多重条件语句

  提供了对开放-封闭原则的完美支持，将算法封装在独立的stragety中，使得它们易于切换，理解和扩展

  策略模式中算法也可以在其他地方复用，避免冗余代码

  利用组合和委托是的Context具有执行算法的能力，这也是继承一种更轻便的替代方案

• 缺点

  拥有许多策略类或者策略对象，实际上比把它们负责的逻辑堆砌在Context中要好

  用户比须了解所有的策略类，才能选择一个最合适的策略类

  使用策略模式会增加许多策略类或者策略对象。不过这要比将它们的逻辑堆砌在Context要好

  要使用stragety，必须要了解所有stragety的细节。此时stragety向客户暴露了其实现，这是有违最少知识原则的

总体来说，使用策略模式来消除众多的条件分支是利大于弊的。在JS中，使用策略模式有时是隐形的，不必要将策略放在特殊的类或者对象中，其策略往往是一个个单独的函数。合理选用策略模式，会让我们的代码更加灵活且易于扩展