前言
提到设计模式可能大家会感觉有点高大上的感觉,其实这个货色的概念很形象,然而在理论开发中还是有很多中央能够应用设计模式的思维,对咱们的代码进行一次优化。本文旨在介绍一些开发中罕用的设计模式,通过例子来进行学习,尽量对概念一带而过。为了讨隔壁前端小姐姐
的崇拜的眼光,一起学一下吧!
注释
1. 适配器模式
概念
:将一个类的接口转化成另外一个接口,以满足用户需要,使类(对象)之间的接口的不兼容问题通过适配器得以解决。
在工作中,有时为了满足需要,在开发新模块的时候须要对老模块做一个兼容,这时候就须要适配器模式。
例如
:
- 办法默认传参
// 参数大于2倡议应用对象进行合并function doSomeThing(obj){ const adapter = { name:"默认姓名", color:"red", size:200, age:20 } for (let i in adapter){ adapter[i] = obj[i] || adapter[i]; } // do some thing}
能够看到这么解决之后咱们无论传入的参数是什么都能够保障对象中领有这几个属性。防止后续逻辑出错。
- 全局封装办法的扩大与兼容。
在vue应用中,咱们通常会将api申请挂载在vue实例上,然而有些老的我的项目是通过封装ajax申请,在对老我的项目进行重构时须要将所有的api申请放到axios上或者fetch上。这就能够应用适配器模式。
// 对fetch 封装伪代码export default class FetchApi{ static get(url){ return new Promise((resolve,reject)=>{ fetch(url).then(...).catch(err=>reject(err)) }) } static post(url,data){ return new Promise(...) }} // 在应用时咱们能够这么应用 const res = await FetchApi.get(url) || {};// 或者 const res = await FetchApi.post(url,params) || {} // 再看一下原有的接口封装形式 伪代码 function Ajax(type,url,data){ const xhr = new XMLHttpRequest() ... if(type === 'GET'){ xhr.open('GET',url+"?"+data,true); xhr.send() }else if(type === 'POST'){ xhr.open('POST',url,true); xhr.setRequestHeader("Content-type",'application/x-www-form-urlencoded') xhr.send(data) } ... } // 调用形式 Ajax("GET",url,data)
在这里咱们能够看到新老接口的接口名不一样,申请传参也不一样。没关系,应用适配器解决。
// 伪代码 async function ajaxAdapterr(type,url,data){ let result if(type === 'GET'){ result = await FetchApi.get(url) || {} }else if(type === 'POST'){ result = await FetchApi.post(url,data) || {} } } async function Ajax(type,url,data){ await ajaxAdapterr(type,url,data); }
这样就能够对原有的ajax申请变更到fetch上,防止一个个去批改页面中的申请。节俭大量了工夫能够用来摸鱼。
2. 策略模式
概念
:将定义的一组算法封装起来,使其相互之间能够替换。封装的算法具备肯定的独立性,不会随客户端的变动而变动。
概念这货色就是长于将人人都懂
的货色形容成人人都不懂
。咱们还是看理论场景吧。
工作中,置信大家肯定写过很多很多的if else判断。当条件越来越多的时候,这种书写形式就会变得特地臃肿,那么就用策略模式优化一下吧。
例如
:
function doSomeThing(type){ if(type === 'pre'){ return 100 }else if(type === 'onSale'){ return 200 }else if(type === 'back'){ return 150 }else if(type === 'fresh'){ return 250 }}// 逻辑会越来越臃肿 用策略模式优化一下function doSomeThing(type){ const priceType = { pre(){ return 100 }, onSale(){ return 200 }, back(){ return 150 }, fresh(){ return 250 } } return priceType[type]()}
能够看到,在应用策略模式优化之后,代码的映射关系很明确,并且更加的灵便直观,前期的保护只须要去在对象中增加办法即可。帅就一个字,我只说一次。这样的代码哪个前端小姐姐看了不说棒呢?
3. 状态模式
概念
:当一个对象的外部状态产生扭转时,会导致其行为的扭转,这看起来像是扭转了对象。
状态模式的概念与策略模式相似,都是封装行为、都通过委托来实现行为散发。然而策略模式外面散发的办法,没有依赖,相互平行,进水不犯河水。而状态模式里,各函数与主体存在肯定的关联。
例如
:
主动咖啡机
class Coffee{ constructor(){ this.state ='黑咖啡'; } stateProcessor = { american: () => { console.log("黑咖啡") }, latte: () => { this.stateProcessor.american(); // 制作黑咖啡 console.log("加奶") }, vanillaLatte: () => { this.stateProcessor.latte(); console.log("加香草糖浆") }, mocha: () => { this.stateProcessor.latte(); console.log('加巧克力') } } changeState(state){ this.state = state; if(!this.stateProcessor[state]){ return console.log("暂无此咖啡") } this.stateProcessor[state]() }}const coffee = new Coffee();coffee.changeState("latte")
状态模式次要解决的是当管制一个对象状态的条件表达式过于简单时的状况,把状态的判断逻辑转移到示意不同状态的一系列类中,能够把简单的判断逻辑简化。
4. 代理模式
概念
:因为一个对象不能间接援用另一个对象,所以须要通过代理对象在这两个对象之间起到中介作用。
代理大家可能平时开发中都有波及到,根本那种代理这里不做介绍,这里介绍一下缓存代理
例如
:
对入参进行求和解决
// addAll办法会对你传入的所有参数做求和操作const addAll = function() { console.log('进行了一次新计算') let result = 0 const len = arguments.length for(let i = 0; i < len; i++) { result += arguments[i] } return result}// 为求和办法创立代理const proxyAddAll = (function(){ // 求和后果的缓存池 const resultCache = {} return function() { // 将入参转化为一个惟一的入参字符串 const args = Array.prototype.join.call(arguments, ',') // 查看本次入参是否有对应的计算结果 if(args in resultCache) { // 如果有,则返回缓存池里现成的后果 return resultCache[args] } return resultCache[args] = addAll(...arguments) }})()
能够看到,在入参统一的状况下,只做了一次计算,后续都是从缓存中取值进行返回,这在计算量特地大的状况下将会极大节省时间开销。
5. 装璜者模式
概念
: 在不扭转原对象的根底上,通过对其进行包装扩大(增加属性或者办法),使得原有对象能够满足更简单的需要。
例如
:
在审批流中,原需要是审批通过回绝都放在了一起进行了解决,前期减少了需要,在回绝时须要显示一个弹框输出回绝起因
// 原有的审批逻辑function approvalOrReject(){ // do some thing}function rejectShowBox(){ this.approvalOrReject(); this.showMessageBox(); // 显示弹框}
如此一来,咱们就实现了“只增加,不批改”的装璜器模式。理论开发中的装璜器模式用途特地多,大家能够用心去发现~
小结
临时先总结这些设计模式吧,后续还会持续整顿增加,请大家点赞珍藏关注咯~
自从用了设计模式,小姐姐都开始对我频频点头了,兄弟们,用起来吧。
因为自己程度无限,文内如有谬误欢送与我分割。