策略模式（Strategy Pattern）又称政策模式，其定义一系列的算法，把它们一个个封装起来，并且使它们可以互相替换。封装的策略算法一般是独立的，策略模式根据输入来调整采用哪个算法。关键是策略的 实现和使用分离 。
注意：本文可能用到一些编码技巧比如 IIFE（Immediately Invoked Function Expression, 立即调用函数表达式），ES6 的语法 let/const、箭头函数、rest 参数，短路运算符 等，如果还没接触过可以点击链接稍加学习 ~
1. 你曾见过的策略模式
现在电子产品种类繁多，尺寸多种多样，有时候你会忍不住想拆开看看里面啥样（想想小时候拆的玩具车还有遥控器），但是螺丝规格很多，螺丝刀尺寸也不少，如果每碰到一种规格就买一个螺丝刀，家里就得堆满螺丝刀了。所以现在人们都用多功能的螺丝刀套装，螺丝刀把只需要一个，碰到不同规格的螺丝只要换螺丝刀头就行了，很方便，体积也变小很多。
再举个栗子，一辆车的轮胎有很多规格，在泥泞路段开的多的时候可以用泥地胎，在雪地开得多可以用雪地胎，高速公路上开的多的时候使用高性能轮胎，针对不同使用场景更换不同的轮胎即可，不需更换整个车。
这些都是策略模式的实例，螺丝刀/车属于封装上下文，封装和使用不同的螺丝刀头/轮胎，螺丝刀头/轮胎这里就相当于策略，可以根据需求不同来更换不同的使用策略。
在这些场景中，有以下特点：
螺丝刀头/轮胎（策略）之间相互独立，但又可以相互替换；
螺丝刀/车（封装上下文）可以根据需要的不同选用不同的策略；
2. 实例的代码实现
具体的例子我们用编程上的例子来演示，比较好量化。
场景是这样的，某个电商网站希望举办一个活动，通过打折促销来销售库存物品，有的商品满 100 减 30，有的商品满 200 减 80，有的商品直接8折出售（想起被双十一支配的恐惧），这样的逻辑交给我们，我们要怎样去实现呢。
通过判断输入的折扣类型来计算计算商品总价的方式，几个 if-else 就满足了需求，但是这样的做法的缺点也很明显：
priceCalculate 函数随着折扣类型的增多， if-else 判断语句会变得越来越臃肿；
如果增加了新的折扣类型或者折扣类型的算法有所改变，那么需要更改 priceCalculate 函数的实现，这是违反开放-封闭原则的；
可复用性差，如果在其他的地方也有类似这样的算法，但规则不一样，上述代码不能复用；
我们可以改造一下，将计算折扣的 算法部分提取出来 保存为一个对象，折扣的 类型作为 key ，这样索引的时候 通过对象的键值索引调用具体的算法 ：
这样 算法的实现和算法的使用就被分开了 ，想添加新的算法也变得十分简单：
如果你希望计算算法隐藏起来，那么可以借助 IIFE 使用闭包的方式，这时需要添加增加策略的入口，以方便扩展：
这样算法就被隐藏起来，并且预留了增加策略的入口，便于扩展。
3. 策略模式的通用实现
根据上面的例子提炼一下策略模式，折扣计算方式可以被认为是策略（Strategy），这些策略之间可以相互替代，而具体折扣的计算过程可以被认为是封装上下文（Context），封装上下文可以根据需要选择不同的策略。
主要有下面几个概念：
Context：封装上下文，根据需要调用需要的策略，屏蔽外界对策略的直接调用，只对外提供一个接口，根据需要调用对应的策略；
Strategy：策略，含有具体的算法，其方法的外观相同，因此可以互相代替；
StrategyMap：所有策略的合集，供封装上下文调用；
结构图如下：
下面使用通用化的方法实现一下。
通用实现看起来似乎比较简单，这里分享一下项目实战。
4. 实战中的策略模式
4.1 表格 formatter
这里举一个 Vue + ElementUI 项目中用到的例子，其他框架的项目原理也类似，和大家分享一下。
Element 的表格控件的 Column 接受一个 formatter 参数，用来格式化内容，其类型为函数，并且还可以接受几个特定参数，像这样： Function(row,column,cellValue,index) 。
以文件大小转化为例，后端经常会直接传 bit 单位的文件大小，那么前端需要根据后端的数据，根据需求转化为自己需要的单位的文件大小，比如 KB/MB。
首先实现文件计算的算法：
那么在组件中我们可以直接：
代码实例可以参看 codepen - 策略模式实战
运行结果如下图：
4.2 表单验证
除了表格中的 formatter 之外，策略模式也经常用在表单验证的场景，这里举一个 Vue + ElementUI 项目的例子，其他框架同理。