8.前端设计模式-策略模式-《前端知识进阶》

admin
admin
admin
0
文章
0
评论
2025-11-01 15:44:37 编程 来源：ZONE.CI 全球网 0 阅读模式
  • 1. 什么是策略模式？
  • 2. 策略模式的实现
  • 3. 策略模式的实际应用
    • （1）表格 formatter
    • （2）表单验证
  • 4. 策略模式的优缺点
  • 5. 策略模式的适用场景
  • 6. 策略模式与其他模式的区别
    • （1）状态模式和策略模式
    • （2） 策略模式和模板方法模式

    1. 什么是策略模式？

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

    在生活中，螺丝的规格有很多，螺丝刀尺寸也不少，如果每碰到一种规格就买一个螺丝刀，那就得堆满了螺丝刀。所以现在人们都用多功能的螺丝刀套装，螺丝刀把只需要一个，碰到不同规格的螺丝只要换螺丝刀头就行了，很方便，体积也变小很多。

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

    这些都是策略模式的实例，螺丝刀/车属于封装上下文，封装和使用不同的螺丝刀头/轮胎，螺丝刀头/轮胎这里就相当于策略，可以根据需求不同来更换不同的使用策略。

    在这些场景中，有以下特点：

    1. 螺丝刀头/轮胎（策略）之间相互独立，但又可以相互替换；

    2. 螺丝刀/车（封装上下文）可以根据需要的不同选用不同的策略；

      2. 策略模式的实现

      来看一个具体的例子，某个电商网站，通过打折促销来销售库存物品，有的商品满 100 减 30，有的商品满 200 减 80，有的商品直接 8 折出售，这样的逻辑该去实现呢。

      1. function priceCalculate(discountType, price) {
      2.  if (discountType === 'minus100_30') {           // 满100减30
      3.      return price - Math.floor(price / 100) * 30
      4.  }
      5.  else if (discountType === 'minus200_80') {  // 满200减80
      6.      return price - Math.floor(price / 200) * 80
      7.  }
      8.  else if (discountType === 'percent80') {    // 8折
      9.      return price * 0.8
      10.  }
      11. }
      12. priceCalculate('minus100_30', 270)    // 输出: 210
      13. priceCalculate('percent80', 250)      // 输出: 200

      通过判断输入的折扣类型来计算商品总价的方式，几个 if-else 就满足了需求，但是这样的做法的缺点也很明显：

    3. priceCalculate 函数随着折扣类型的增多，if-else 判断语句会变得越来越臃肿；

    4. 如果增加了新的折扣类型或者折扣类型的算法有所改变，那么需要更改 priceCalculate 函数的实现，这是违反开放-封闭原则的；
    5. 可复用性差，如果在其他的地方也有类似这样的算法，但规则不一样，上述代码不能复用；

    下面来改造一下，将计算折扣的算法部分提取出来保存为一个对象，折扣的类型作为 key，这样索引的时候通过对象的键值索引调用具体的算法：

    1. const DiscountMap = {
    2.     minus100_30: function(price) {
    3.         return price - Math.floor(price / 100) * 30
    4.     },
    5.     minus200_80: function(price) {
    6.         return price - Math.floor(price / 200) * 80
    7.     },
    8.     percent80: function(price) {
    9.         return price * 0.8
    10.     }
    11. }
    12. // 计算总售价
    13. function priceCalculate(discountType, price) {
    14.     return DiscountMap[discountType] && DiscountMap[discountType](price)
    15. }
    16. priceCalculate('minus100_30', 270)
    17. priceCalculate('percent80', 250)
    18. // 输出: 210
    19. // 输出: 200

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

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

    如果希望计算算法隐藏起来，那么可以借助 IIFE 使用闭包的方式，这时需要添加增加策略的入口，以方便扩展：

    1. const PriceCalculate = (function() {
    2.     /* 售价计算方式 */
    3.     const DiscountMap = {
    4.         minus100_30: function(price) {      // 满100减30
    5.             return price - Math.floor(price / 100) * 30
    6.         },
    7.         minus200_80: function(price) {      // 满200减80
    8.             return price - Math.floor(price / 200) * 80
    9.         },
    10.         percent80: function(price) {        // 8折
    11.             return price * 0.8
    12.         }
    13.     }
    15.     return {
    16.         priceClac: function(discountType, price) {
    17.             return DiscountMap[discountType] && DiscountMap[discountType](price)
    18.         },
    19.         addStrategy: function(discountType, fn) {        // 注册新计算方式
    20.             if (DiscountMap[discountType]) return
    21.             DiscountMap[discountType] = fn
    22.         }
    23.     }
    24. })()
    25. PriceCalculate.priceClac('minus100_30', 270)    // 输出: 210
    26. PriceCalculate.addStrategy('minus150_40', function(price) {
    27.     return price - Math.floor(price / 150) * 40
    28. })
    29. PriceCalculate.priceClac('minus150_40', 270)    // 输出: 230

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

    下面就来实现一个通用的策略模式，可以根据上面的例子提炼一下策略模式，折扣计算方式可以被认为是策略（Strategy），这些策略之间可以相互替代，而具体折扣的计算过程可以被认为是封装上下文（Context），封装上下文可以根据需要选择不同的策略。

    策略模式中主要有下面概念：

    1. Context ：封装上下文，根据需要调用需要的策略，屏蔽外界对策略的直接调用，只对外提供一个接口，根据需要调用对应的策略；
    2. Strategy ：策略，含有具体的算法，其方法的外观相同，因此可以互相代替；
    3. StrategyMap ：所有策略的合集，供封装上下文调用；

    结构图如下：策略模式 - 图1下面使用通用化的方法实现一下。

    1. const StrategyMap = {}
    2. function context(type, ...rest) {
    3.     return StrategyMap[type] && StrategyMap[type](...rest)
    4. }
    5. StrategyMap.minus100_30 = function(price) { 
    6.       return price - Math.floor(price / 100) * 30
    7. }
    8. context('minus100_30', 270)            // 输出: 210

    3. 策略模式的实际应用

    （1）表格 formatter

    Element UI 的表格控件的 Column 接受一个 formatter 参数，用来格式化内容，其类型为函数，并且还可以接受几个特定参数，像这样： Function(row, column, cellValue, index)。

    以文件大小转化为例，后端经常会直接传 bit 单位的文件大小，那么前端需要根据后端的数据，根据需求转化为自己需要的单位的文件大小，比如 KB/MB。

    首先实现文件计算的算法：

    1. export const StrategyMap = {
    2.     // Strategy 1: 将文件大小（bit）转化为 KB 
    3.     bitToKB: val => {
    4.         const num = Number(val)
    5.         return isNaN(num) ? val : (num / 1024).toFixed(0) + 'KB'
    6.     },
    7.     // Strategy 2: 将文件大小（bit）转化为 MB 
    8.     bitToMB: val => {
    9.         const num = Number(val)
    10.         return isNaN(num) ? val : (num / 1024 / 1024).toFixed(1) + 'MB'
    11.     }
    12. }
    13. // Context: 生成el表单 formatter 
    14. const strategyContext = function(type, rowKey){ 
    15.   return function(row, column, cellValue, index){
    16.       StrategyMap[type](row[rowKey])
    17.   }
    18. }
    19. export default strategyContext

    那么在组件中可以直接使用：

    1. <template>
    2.     <el-table :data="tableData">
    3.         <el-table-column prop="date" label="日期"></el-table-column>
    4.         <el-table-column prop="name" label="文件名"></el-table-column>
    5.         <!-- 直接调用 strategyContext -->
    6.         <el-table-column prop="sizeKb" label="文件大小(KB)"
    7.                          :formatter='strategyContext("bitToKB", "sizeKb")'>
    8.         </el-table-column>
    9.         <el-table-column prop="sizeMb" label="附件大小(MB)"
    10.                          :formatter='strategyContext("bitToMB", "sizeMb")'>
    11.         </el-table-column>
    12.     </el-table>
    13. </template>
    14. <script type='text/javascript'>
    15.     import strategyContext from './strategyContext.js'
    17.     export default {
    18.         name: 'ElTableDemo',
    19.         data() {
    20.             return {
    21.                 strategyContext,
    22.                 tableData: [
    23.                     { date: '2019-05-02', name: '文件1', sizeKb: 1234, sizeMb: 1234426 },
    24.                     { date: '2019-05-04', name: '文件2', sizeKb: 4213, sizeMb: 8636152 }]
    25.             }
    26.         }
    27.     }
    28. </script>
    29. <style scoped></style>

    运行结果如下图：策略模式 - 图2

    （2）表单验证

    除了表格中的 formatter 之外，策略模式也经常用在表单验证的场景。Element UI 的 Form 表单 具有表单验证功能，用来校验用户输入的表单内容。实际需求中表单验证项一般会比较复杂，所以需要给每个表单项增加 validator 自定义校验方法。

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

    1. // src/utils/validates.js
    2. // 姓名校验 由2-10位汉字组成 
    3. export function validateUsername(str) {
    4.     const reg = /^[\u4e00-\u9fa5]{2,10}$/
    5.     return reg.test(str)
    6. }
    7. // 手机号校验 由以1开头的11位数字组成  
    8. export function validateMobile(str) {
    9.     const reg = /^1\d{10}$/
    10.     return reg.test(str)
    11. }
    12. // 邮箱校验 
    13. export function validateEmail(str) {
    14.     const reg = /^[a-zA-Z0-9_-]+@[a-zA-Z0-9_-]+(\.[a-zA-Z0-9_-]+)+$/
    15.     return reg.test(str)
    16. }

    然后在 utils/index.js 中增加一个柯里化方法，用来生成表单验证函数：

    1. // src/utils/index.js
    2. import * as Validates from './validates.js'
    3. // 生成表格自定义校验函数 
    4. export const formValidateGene = (key, msg) => (rule, value, cb) => {
    5.     if (Validates[key](value)) {
    6.         cb()
    7.     } else {
    8.         cb(new Error(msg))
    9.     }
    10. }

    上面的 formValidateGene 函数接受两个参数，第一个是验证规则，也就是 src/utils/validates.js 文件中提取出来的通用验证规则的方法名，第二个参数是报错的话表单验证的提示信息。

    1. <template>
    2.     <el-form ref="ruleForm"
    3.              label-width="100px"
    4.              class="demo-ruleForm"
    5.              :rules="rules"
    6.              :model="ruleForm">
    8.         <el-form-item label="用户名" prop="username">
    9.             <el-input v-model="ruleForm.username"></el-input>
    10.         </el-form-item>
    12.         <el-form-item label="手机号" prop="mobile">
    13.             <el-input v-model="ruleForm.mobile"></el-input>
    14.         </el-form-item>
    16.         <el-form-item label="邮箱" prop="email">
    17.             <el-input v-model="ruleForm.email"></el-input>
    18.         </el-form-item>
    19.     </el-form>
    20. </template>
    21. <script type='text/javascript'>
    22.     import * as Utils from '../utils'
    24.     export default {
    25.         name: 'ElTableDemo',
    26.         data() {
    27.             return {
    28.                 ruleForm: { pass: '', checkPass: '', age: '' },
    29.                 rules: {
    30.                     username: [{
    31.                         validator: Utils.formValidateGene('validateUsername', '姓名由2-10位汉字组成'),
    32.                         trigger: 'blur'
    33.                     }],
    34.                     mobile: [{
    35.                         validator: Utils.formValidateGene('validateMobile', '手机号由以1开头的11位数字组成'),
    36.                         trigger: 'blur'
    37.                     }],
    38.                     email: [{
    39.                         validator: Utils.formValidateGene('validateEmail', '不是正确的邮箱格式'),
    40.                         trigger: 'blur'
    41.                     }]
    42.                 }
    43.             }
    44.         }
    45.     }
    46. </script>

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

    运行结果：策略模式 - 图3

    4. 策略模式的优缺点

    策略模式将算法的实现和使用拆分，这个特点带来了很多优点：

    1. 策略之间相互独立，但策略可以自由切换，这个策略模式的特点给策略模式带来很多灵活性，也提高了策略的复用率；
    2. 如果不采用策略模式，那么在选策略时一般会采用多重的条件判断，采用策略模式可以避免多重条件判断，增加可维护性；
    3. 可扩展性好，策略可以很方便的进行扩展；

    策略模式的缺点：

    1. 策略相互独立，因此一些复杂的算法逻辑无法共享，造成一些资源浪费；

    2. 如果用户想采用什么策略，必须了解策略的实现，因此所有策略都需向外暴露，这是违背迪米特法则/最少知识原则的，也增加了用户对策略对象的使用成本。

      5. 策略模式的适用场景

      策略模式的使用场景如下：

    3. 多个算法只在行为上稍有不同的场景，这时可以使用策略模式来动态选择算法；

    4. 算法需要自由切换的场景；
    5. 有时需要多重条件判断，那么可以使用策略模式来规避多重条件判断的情况；

      6. 策略模式与其他模式的区别

      （1）状态模式和策略模式

      状态模式和策略模式在之前的代码就可以看出来，看起来比较类似，他们的区别：
    • 状态模式： 重在强调对象内部状态的变化改变对象的行为，状态类之间是平行的，无法相互替换；
    • 策略模式： 策略的选择由外部条件决定，策略可以动态的切换，策略之间是平等的，可以相互替换；

    状态模式的状态类是平行的，意思是各个状态类封装的状态和对应的行为是相互独立、没有关联的，封装的业务逻辑可能差别很大毫无关联，相互之间不可替换。但是策略模式中的策略是平等的，是同一行为的不同描述或者实现，在同一个行为发生的时候，可以根据外部条件挑选任意一个实现来进行处理。

    （2） 策略模式和模板方法模式

    策略模式和模板方法模式的作用比较类似，但是结构和实现方式有点不一样。

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

    版权声明

    本站仅做备份收录，仅供研究与教学参考之用。
    读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。

    ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
    ZONE.CI 全球网
    安全领域涉猎者-乌云独行地带
    以太坊cppgolang区别 编程

    以太坊cppgolang区别

    以太坊是一种去中心化的开源平台，它采用智能合约技术，旨在构建和运行不受干扰的分布式应用程序。作为目前最受欢迎的区块链平台之一，以太坊提供了多种编程语言的支持，其
    12-282 评论
    progolang 编程

    progolang

    Go语言（Golang）是由Google开发的一门静态类型编程语言。作为一名专业的Golang开发者，我深知这门语言的优势和特点。在本文中，我将介绍Golang
    12-281 评论
    golangn个发送者 编程

    golangn个发送者

    Golang是一种开源的编程语言，由Google团队开发，旨在提高程序的并发性和简化软件开发过程。在Go语言中，有时需要向多个接收者发送信息。本文将介绍如何在G
    12-280 评论
    golang技能图谱 编程

    golang技能图谱

    从互联网行业的快速发展到人工智能技术的日益成熟，各种编程语言也应运而生。而在这众多的编程语言中，Golang（即Go）作为一门强大且高效的开发语言备受关注。Go
    12-281 评论
    ZONE.CI 全球网 | 安全领域涉猎者-乌云独行地带
    安全领域涉猎者-乌云独行地带
    ZONE.CI 全球网
    评论：0   参与：  7