一、策略模式
策略模式是定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。
而且策略模式是重构小能力，特别适合拆分“胖逻辑”。
这个定义乍一看会有点懵，不过通过下面的例子就能慢慢理解它的意思。
先来看一个真实场景
某次活动要做差异化询价。啥是差异化询价？就是说同一个商品，我通过在后台给它设置不同的价格类型，可以让它展示不同的价格。具体的逻辑如下：
- 当价格类型为“预售价”时，满 100 – 20，不满 100 打 9 折
- 当价格类型为“大促价”时，满 100 – 30，不满 100 打 8 折
- 当价格类型为“返场价”时，满 200 – 50，不叠加
- 当价格类型为“尝鲜价”时，直接打 5 折
首先将四种价格做了标签化：
预售价 - pre
大促价 - onSale
返场价 - back
尝鲜价 - fresh
大部分人可能会这么写
// 询价方法，接受价格标签和原价为入参
function askPrice(tag, originPrice) {
// 处理预热价
if(tag === 'pre') {
if(originPrice >= 100) {
return originPrice - 20
}
return originPrice * 0.9
}
// 处理大促价
if(tag === 'onSale') {
if(originPrice >= 100) {
return originPrice - 30
}
return originPrice * 0.8
}
// 处理返场价
if(tag === 'back') {
if(originPrice >= 200) {
return originPrice - 50
}
return originPrice
}
// 处理尝鲜价
if(tag === 'fresh') {
return originPrice * 0.5
}
}
上述代码运行起来确实没啥毛病。但也只是“运行起来”没毛病而已。
问题点：
- 首先，它违背了“单一功能”原则。一个函数里面竟然处理了四个逻辑，这个函数的逻辑太胖了！而且单个能力很难被抽离复用。
- 另外，它还违背了“开放封闭”原则。假如再加一个满 100 – 50 的“新人价”就只能在这个函数中修改代码，继续加if逻辑。
重构询价逻辑
现在我们基于设计原则思想（“单一功能”和开放封闭”原则），一点一点改造掉这个臃肿的 askPrice。
单一功能改造
首先，我们赶紧把四种询价逻辑提出来，让它们各自为政：
// 处理预热价
function prePrice(originPrice) {
if(originPrice >= 100) {
return originPrice - 20
}
return originPrice * 0.9
}
// 处理大促价
function onSalePrice(originPrice) {
if(originPrice >= 100) {
return originPrice - 30
}
return originPrice * 0.8
}
// 处理返场价
function backPrice(originPrice) {
if(originPrice >= 200) {
return originPrice - 50
}
return originPrice
}
// 处理尝鲜价
function freshPrice(originPrice) {
return originPrice * 0.5
}
function askPrice(tag, originPrice) {
// 处理预热价
if(tag === 'pre') {
return prePrice(originPrice)
}
// 处理大促价
if(tag === 'onSale') {
return onSalePrice(originPrice)
}
// 处理返场价
if(tag === 'back') {
return backPrice(originPrice)
}
// 处理尝鲜价
if(tag === 'fresh') {
return freshPrice(originPrice)
}
}
OK，我们现在至少做到了一个函数只做一件事。现在每个函数都有了自己明确的、单一的分工。
到这里，在单一功能原则的指引下，我们已经解决了一半的问题。我们已经把“询价逻辑的执行”给摘了出去，并且实现了不同询价逻辑之间的解耦。
开放封闭改造
如果现在要想给 askPrice 增加新人询价逻辑，应该怎么办？
如果在 askPrice 里面，新增了一个 if-else 判断。这样其实还是在修改 askPrice 的函数体，没有实现“对扩展开放，对修改封闭”的效果。
那么我们应该怎么做？我们仔细想想，这么多 if-else，我们的目的到底是什么？是不是就是为了把 询价标签-询价函数 这个映射关系给明确下来？那么在 JS 中，有没有什么既能够既帮我们明确映射关系，同时不破坏代码的灵活性的方法呢？答案就是对象映射！
咱们完全可以把询价算法全都收敛到一个对象里去：
// 定义一个询价处理器对象
const priceProcessor = {
pre(originPrice) {
if (originPrice >= 100) {
return originPrice - 20;
}
return originPrice * 0.9;
},
onSale(originPrice) {
if (originPrice >= 100) {
return originPrice - 30;
}
return originPrice * 0.8;
},
back(originPrice) {
if (originPrice >= 200) {
return originPrice - 50;
}
return originPrice;
},
fresh(originPrice) {
return originPrice * 0.5;
},
};
当我们想使用其中某个询价算法的时候：通过标签名去定位就好了：
// 询价函数
function askPrice(tag, originPrice) {
return priceProcessor[tag](originPrice)
}
如此一来，askPrice 函数里的 if-else 大军彻底被咱们消灭了。这时候如果你需要一个新人价，只需要给 priceProcessor 新增一个映射关系即可：
priceProcessor.newUser = function (originPrice) {
if (originPrice >= 100) {
return originPrice - 50;
}
return originPrice;
}
这样一来，询价逻辑的分发也变成了一个清清爽爽的过程。
二、状态模式
状态模式(State Pattern) ：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。
状态模式主要解决的是当控制一个对象状态的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简化。
状态模式和策略模式宛如一对孪生兄弟——它们长得很像、解决的问题也可以说没啥本质上的差别。
以咖啡机为例讲状态模式
在这个能做四种咖啡的咖啡机体内，蕴含着四种状态：
- 美式咖啡态（american)：只吐黑咖啡
- 普通拿铁态(latte)：黑咖啡加点奶
- 香草拿铁态（vanillaLatte）：黑咖啡加点奶再加香草糖浆
- 摩卡咖啡态(mocha)：黑咖啡加点奶再加点巧克力
大部分人第一反应还是会先用if-else完成如下
class CoffeeMaker {
constructor() {
/**
这里略去咖啡机中与咖啡状态切换无关的一些初始化逻辑
**/
// 初始化状态，没有切换任何咖啡模式
this.state = 'init';
}
// 关注咖啡机状态切换函数
changeState(state) {
// 记录当前状态
this.state = state;
if(state === 'american') {
// 这里用 console 代指咖啡制作流程的业务逻辑
console.log('我只吐黑咖啡');
} else if(state === 'latte') {
console.log(`给黑咖啡加点奶`);
} else if(state === 'vanillaLatte') {
console.log('黑咖啡加点奶再加香草糖浆');
} else if(state === 'mocha') {
console.log('黑咖啡加点奶再加点巧克力');
}
}
}
测试一下，完美无缺：
const mk = new CoffeeMaker();
mk.changeState('latte'); // 输出 '给黑咖啡加点奶'
但是考虑到设计原则中的“单一职责、开放封闭”原则，我们还需要如同上面策略模式中的改造方法进行对上面代码的改造。
根据“单一职责、开放封闭”原则改造后
const stateToProcessor = {
american() {
console.log('我只吐黑咖啡');
},
latte() {
this.american();
console.log('加点奶');
},
vanillaLatte() {
this.latte();
console.log('再加香草糖浆');
},
mocha() {
this.latte();
console.log('再加巧克力');
}
}
class CoffeeMaker {
constructor() {
/**
这里略去咖啡机中与咖啡状态切换无关的一些初始化逻辑
**/
// 初始化状态，没有切换任何咖啡模式
this.state = 'init';
}
// 关注咖啡机状态切换函数
changeState(state) {
// 记录当前状态
this.state = state;
// 若状态不存在，则返回
if(!stateToProcessor[state]) {
return ;
}
stateToProcessor[state]();
}
}
const mk = new CoffeeMaker();
mk.changeState('latte');
输出结果符合预期：
我只吐黑咖啡
加点奶
现在看起来好像很完善了，但是stateToProcessor 里的工序函数，感知不到咖啡机的内部状况。
为了让stateToProcessor里的工序函数能感知到咖啡机的内部状况，把状态-行为映射对象作为主体类对应实例的一个属性添加进去就行了：
class CoffeeMaker {
constructor() {
/**
这里略去咖啡机中与咖啡状态切换无关的一些初始化逻辑
**/
// 初始化状态，没有切换任何咖啡模式
this.state = 'init';
// 初始化牛奶的存储量
this.leftMilk = '500ml';
}
stateToProcessor = {
that: this,
american() {
// 尝试在行为函数里拿到咖啡机实例的信息并输出
console.log('咖啡机现在的牛奶存储量是:', this.that.leftMilk)
console.log('我只吐黑咖啡');
},
latte() {
this.american()
console.log('加点奶');
},
vanillaLatte() {
this.latte();
console.log('再加香草糖浆');
},
mocha() {
this.latte();
console.log('再加巧克力');
}
}
// 关注咖啡机状态切换函数
changeState(state) {
this.state = state;
if (!this.stateToProcessor[state]) {
return;
}
this.stateToProcessor[state]();
}
}
const mk = new CoffeeMaker();
mk.changeState('latte');
输出结果为：
咖啡机现在的牛奶存储量是: 500ml
我只吐黑咖啡
加点奶
如此一来，我们就可以在 stateToProcessor 轻松拿到咖啡机的实例对象，进而感知咖啡机这个主体了。
策略模式和状态模式的异同点
策略模式和状态模式确实是相似的，它们都封装行为、都通过委托来实现行为分发。
但策略模式中的行为函数是“潇洒”的行为函数（策略模式是对算法的封装，封装的算法可以单独使用），它们不依赖调用主体、互相平行、各自为政，井水不犯河水。而状态模式中的行为函数，首先是和状态主体之间存在着关联，由状态主体把它们串在一起；另一方面，正因为关联着同样的一个（或一类）主体，所以不同状态对应的行为函数可能并不会特别割裂。
前端中的状态模式应用——javascript-state-machine
暂无评论内容