晋城 网站建设,枸橼酸西地那非片的作用及功效,sketch做网站线框图,用于做网站的软件一、策略模式
策略模式是定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。 而且策略模式是重构小能力#xff0c;特别适合拆分“胖逻辑”。
这个定义乍一看会有点懵#xff0c;不过通过下面的例子就能慢慢理解它的意思。
先来看一个真实场景
某次活动要做…一、策略模式
策略模式是定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。 而且策略模式是重构小能力特别适合拆分“胖逻辑”。
这个定义乍一看会有点懵不过通过下面的例子就能慢慢理解它的意思。
先来看一个真实场景
某次活动要做差异化询价。啥是差异化询价就是说同一个商品我通过在后台给它设置不同的价格类型可以让它展示不同的价格。具体的逻辑如下
当价格类型为“预售价”时满 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 最后
整理了75个JS高频面试题并给出了答案和解析基本上可以保证你能应付面试官关于JS的提问。 有需要的小伙伴可以点击下方卡片领取无偿分享
