前言
2022年,前端技术依旧日新月异,各种新兴技术或业务解决方案层出不穷。但我始终认为,在变与不变之间,唯有经典永恒,设计模式就是经典之一。在笔者从业期间,见过很多不同人写的代码,层次有高有低,将设计模式运用地行云流水的大佬,写出的代码总是令人觉着舒适优雅,有时恨不得顿足品读一番,相传小米创始人雷军写的代码就如同诗一般优雅;相反,不懂设计模式的开发者写出的代码总是一言难尽,甚至没有看下去的欲望,恨不得当场重构。。。
1995 年,GoF四人组开创性地提出 23 种设计模式,设计模式是前辈们对代码开发经验的总结,是解决特定问题的一系列套路,是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。站在巨人的肩膀上,能少走很多弯路,看到更多别样的风景。
本系列文章,笔者将会介绍在前端开发过程中,十分实用的一些设计模式,欢迎各位大佬补充讨论,本篇文章将介绍笔者最青睐的策略模式。
策略模式(if-else的救世主)
策略模式(Strategy Pattern)指的是定义一系列的算法,把它们一个个封装起来,目的就是将算法的使用与算法的实现分离开来。
这里所指的算法,类似于一个策略,策略模式的核心思想就是在一个计算方法中把容易变化的算法抽出来作为“策略”参数传进去,从而使得新增策略不必修改原有逻辑。
本质上来看就是我们老生常谈的解耦。如果一个复杂的系统,如果所有策略都耦合在业务逻辑里,日复一日随着需求的改变和增加,代码越来越庞杂,可维护性越来越低,但如果将策略与业务解耦,我们就可以独立维护这些策略,为业务带来更灵活的变化。
实际操作
举一个比较常见的例子,我们会遇到枚举值转换的问题,比如下面我们需要维护一个优惠券的类型,简单粗暴的想我们会直接用if-else直接梭哈。
const getCouponText = (type) => { if (type === 1) { return '免费券' } else if (type === 2) { return '立减券' } else if (type === 3) { return '折扣券' } ... }但如果我们想要我们的代码可维护性更高的话,首先我们需要对这个枚举值做一个统一的维护管理(枚举值统一管理是笔者推荐的,可以使得代码更语义化,不属于策略模式的内容),提升代码的可读性,然后使用对象映射来将逻辑分离出来,解放了if-else,特别是逻辑非常重的时候,用这个方法逻辑更为清晰明了。
const COUPON_TYPE = { FREE: 1, // 免费 DISCOUNT: 2, // 折扣 REDUCE: 3, // 立减 }; const COUPON_TYPES = { [COUPON_TYPE.FREE]: '免费券', [COUPON_TYPE.DISCOUNT]: '折扣券', [COUPON_TYPE.REDUCE]: '立减券' } const getCouponText = (type) => { return COUPON_TYPES[type]||'' }
在具体的业务中,我们也会使用到这些枚举值,来对不同的枚举进行不同的操作判断,这时候我们往往又会写一些if-else判断逻辑,随着业务类型的增加,我们只能不停地往里面堆代码
const handleType = (type) => { if (type === 1) { do sth do sth } else if (type === 2) { do sth do sth } else if (type === 3) { do sth do sth } ... }
同样地,我们使用策略模式也可以将这段代码变得更为优雅,使用一个对象专门用来维护这些对应的方法事件,每个类型对应一个方法,遵循了单一原则。
const couponFunctions = { [COUPON_TYPE.FREE]: () => { do sth}, [COUPON_TYPE.DISCOUNT]: () => { do sth }, [COUPON_TYPE.REDUCE]: () => { do sth } } const handleType = (type) => { couponFunctions[type] && couponFunctions[type]() }
笔者认为策略模式是非常好用的,特别是对于一些比较"重"的逻辑,各种if-else乱象,使用策略模式能够让代码更通俗易懂,每次改动代码的时候,只需要修改对应的内容就行,不至于在庞杂的逻辑下慌乱了阵脚。
标签:do,浅谈,COUPON,前端,sth,else,设计模式,type,代码 From: https://www.cnblogs.com/caihongmin/p/16768251.html