javascript设计模式源码
㈠ 设计模式(五)行为型模式
在上一篇结构型模式中,我们以功能为基本单位,研究了一些设计模式,用于实现功能转换、功能组合、功能封装等目的。
我们知道,面向对象编程有两个核心元素:对象、对象间通信协作。从面向对象的角度看,任何系统和功能,都是由一个个对象,相互分工合作实现的。推而广之,很多系统也都是这样组织和运行的。
本章的设计模式,列举了通用场景下常用功能机制的经典实现方法,讲解了经典实现中是如何高效组织对象、控制对象协作交互的,具有很好的参考价值。
示例:https://www.runoob.com/design-pattern/chain-of-responsibility-pattern.html
责任链模式,就是把程序处理对象前后排列起来,形成一条处理线。处理线上需要被处理的信息,在处理线上向下传递,任何一个节点都可以随时中断传递。
GUI系统中的事件传递机制(在javascript中叫做事件冒泡),是责任链模式最典型的应用之一。
当某一事件发生时,最顶层GUI对象会首先收到事件,但是它先不处理,而是依次交给命中的子GUI对象处理。当子GUI对象返回为False时,表示事件未被接收,此时父GUI对象才真正对发生的事件进行业务处理。
可以看出,事件传递机制,是一种增强版的责任链模式,它的节点处理权,经历了向下和向上的双向传递过程。
总结:当项目中一个数据对象,需要被多个处理对象进行处理时,可以将处理对象链接起来,然后把数据对象传递给头节点,随着处理的进行,数据对象的处理权会在处理链中流动,从而完成整个处理过程。
责任链模式结构适用于需求固定的场景,用于实现简单高效的处理机制。假如需求不断变化,而且功能很复杂,那么用责任链模式很可能就无法胜任了,需要采用新的高复杂度的设计。例如,如果想要数据对象在所有处理对象中根据状态来实现跳转,可以选择使用状态机等其他方案来实现。
示例:https://www.runoob.com/design-pattern/command-pattern.html
想要实现撤销、重做、事务等功能,可以使用此设计模式。通常在编辑器、数据库中有此类功能需求。
命令也就是请求,或者叫调用。命令模式要求将请求参数和请求相关的方法封装在一起。
请求对象中封装了实现“撤销”、“重做”、“事务”功能所需要的所有信息,实现了关联信息的高内聚,所以可以实现我们想要的功能。
例如,可以在请求对象中保存修改之前的值、修改之后的值。利用修改之前的值,可以实现“撤销”功能;利用修改之后的值,可以实现“重做”功能。如果将所有请求对象都记录下来,并按照先后顺序排列起来,形成“撤销重做”堆栈,这样就可以实现连续的“撤销”、“重做”。“事务”则是“撤销”与“重做”的结合体,正常执行流程等同于“重做”,发生错误需要回滚,等同于“撤销”。
如果不采用这种方式,会导致实现这些功能的信息,分散在源码中多个地方,或者已经丢失,没有保存,就无法实现“撤销”、“重做”、“事务”功能。
同时,实现请求参数高内聚,也可以很方便地将它们保存到磁盘上,保存到文件的过程叫做“序列化”,从文件中读取的过程叫“反序列化”。这里的序列指的就是二进制流。
Qt中与命令模式相关的部分是:Undo Framework,里面有示例项目,不熟悉的同学可以抽点时间看一看。
示例:https://www.runoob.com/design-pattern/interpreter-pattern.html
顾名思义,解释器模式是用来实现解释器的。 解释器是这样一个程序:解释器以符合语法的文本为输入,解释输入内容,完成一定的计算功能。文本可以在程序运行时动态加载,动态解释、动态执行。
实现简单的解释器:命令行程序,如ping命令、cd命令等; 实现复杂的解释器:脚本语言解释器,如python,lua,javascript;计算器。
我们知道,在GUI图形用户界面被发明之前,人类和程序之间的交互是通过敲命令行实现的,缺点是使用难度较大,门槛较高。 在GUI发明以后,交互更加友好,电脑更加易于使用了,所以也更加普及了。
但是GUI交互的缺点在于,不够灵活,对参数的控制粒度不够细致。例如,现在大多数开发者都使用集成开发环境来开发软件,一般情况下都使用默认参数,比较方便。但是如果你想要更改某些编译选项,可能还是需要直接修改底层的编译命令。命令相对于GUI元素更加灵活,过于灵活的地方用GUI比较难于实现,例如组合、递归、跳转等等。在这些场景下,使用解释器是非常合适的。但是通常情况下,这个模式并不常用。
示例:https://www.runoob.com/design-pattern/iterator-pattern.html
在需要多次遍历同一个数据集合的时候,为了少些一些for,或者想要把遍历过程封装起来,降低耦合,就可以使用迭代器模式。这个模式非常常用。
迭代器就是一个专门用来遍历数组的类。它只需要实现两个接口:hasNext()、next()。 hasNext()接口用于控制循环何时停止;next()接口用于取出当前位置的数据元素,并将遍历指针指向下一个元素。 当然,构造迭代器对象的时候,需要将数据集合传递给迭代器,让迭代器知道要遍历哪些数据。
原本需要用for循环来遍历的代码,现在通过封装,提取出了“遍历”这一功能所需要的必要信息,定义了两个接口,把不必要暴露的信息封装在了迭代器中,妥妥的实现了解耦。
示例:https://www.runoob.com/design-pattern/mediator-pattern.html
中介者模式是指,在原本直接通信的对象之间,添加一个通信中间层,使对象间通信变为间接通信,降低对象间的耦合。
此模式和代理模式基本思想上是一致的。二者的区别是:代理模式是通过加一个中间层,来实现两个原本很难交互的功能主体,实现顺畅交互;中介者模式是为了降低对象间通信时的耦合而提出的,为的是提高代码的可维护性。
比较大的项目中会用到,一般存在于某些框架中。因为大的项目中对象繁多,通信也比较复杂,适合使用中介者模式。
在大的项目中,一般会有一个全局的通信管理器,任何对象都可以使用通信管理器提供的接口,将自己注册为某一个具有唯一ID消息的发送者和接收者。这样发送者只需要发送消息,不需要管谁来接收,不需要拥有发送者的实例指针,发出消息后,已注册的接收者都会收到消息。接收者不需要管信号是谁发的,即不需要拥有发送者的实例指针。
所以,中介者模式也可以叫“通信中介模式”。
示例:https://www.runoob.com/design-pattern/memento-pattern.html
这个模式和状态存档功能是绑定在一起的。为了在程序中实现状态存档功能,可以使用备忘录模式。
原例子中有三个类,个人觉得没有必要,这里我们简化成两个类,即备忘录模式中有两个类:状态对象类和状态对象管理类。 状态对象类是状态字段是集合,并提供了存取接口;状态对象管理类负责组织和保存状态对象。当然实际实现中可以根据需求增加类,配合使用,完成状态保存恢复。
当一个对象会影响到其他多个对象时,即当对象间存在一对多关系时,使用观察者模式。 一般应用于单向通知的场景,如GUI中鼠标事件、按键事件、窗口事件通知。使用Qt中的信号槽机制可以实现此模式。
“一”是指发生变化的那个对象,“多”是指需要获取此变化通知的对象组。其中,变化消息是单向地由“一”到“多”传递的。如果不是单向的或者对象间不是一对多的关系,更加复杂,就需要重新思考其他对象间通信模型。
如果不使用此模式,可能会导致观察者不能动态增加或删除;可能会造成发送者的业务代码和接收者的响应代码混在一起,耦合严重。
使用此模式,需要为观察者设计一个基类,并设计一个接收通知的接口,所有观察者需要实现通知接口;所有观察者指针可以保存在队列中,实现动态增删。
状态模式用于实现状态机。 如果一个程序功能中存在某些状态,在一定情况下,这些状态可以互相转换,并且在转换前后需要作出对应的操作,这种情况下使用状态机来实现就非常合适。
如果不使用状态机(状态模式),一般的实现方法是使用一连串的if-else,或者使用长长的switch-case来实现。这样做的缺点,一方面状态判断不够高效,另一方面是业务代码集中在一块,不好维护。
使用状态机,每个状态都是一个类,相关的业务代码分布到各自的状态类中,能够实现不同的状态及与状态相关的业务代码解耦。同时某个状态和下一个状态是关联好的,在状态切换时,效率更高,不需要执行长长的判断。
Qt中已实现状态机框架,The State Machine Framework,在此框架下,我们可以更加专注于业务实现,而不是状态机本身的技术细节。
示例:https://www.runoob.com/design-pattern/null-object-pattern.html
使用基类保存子类对象通常有两种做法:
第一种方法用指针是基本方法,但是指针用起来要非常小心,要考虑内存释放的问题。此时空对象就可以用空指针表示。 第二种方法用基类对象保存子类对象,这种方法使用起来相对省心,不用与指针打交道,使用者不用直接管理内存。例如Qt中的Qt XML C++ Classes类的设计就是采用这种方式设计的。这种情况下,因为不使用指针,就需要使用空对象来代替空指针。
可以仿造Qt XML中的类进行设计。一般需要提供isNull()接口,对象类型转换接口等。
策略模式和桥接模式类似,用于实现功能切换与组合。二者区别在于,策略模式专注于一个功能的不同实现方式;桥接模式专注于多个功能之间的组合。
将功能抽象成单独的类,功能切换只需要切换不同的功能子类即可,同一个功能需要实现同一个功能接口。
示例:https://www.runoob.com/design-pattern/template-pattern.html
模板模式应该是我们最熟悉的。 这里的模板就是接口类,接口类定义了使用者和功能提供者之间交互的函数列表。子类负责功能的具体实现。
示例:https://www.runoob.com/design-pattern/visitor-pattern.html
访问者模式用于将数据结构与数据操作相分离。
访问者模式和迭代器模式类似。迭代器模式一般用来遍历数组,所以没有把for封装起来。而访问者模式可以遍历一切类型的数据结构,具体的遍历过程被封装在接收者内部。同时,对每一个遍历得到的数组元素的操作,被封装在访问者内部。每一种对元素不同的操作,都需要新建一个访问者类。
接收者需要实现accept()接口,访问者需要实现visit()接口。
每种设计模式都有使用场景,都有优点和缺点。随着需求的改变,任何一种设计模式可能都将不再适用。
㈡ JavaScript设计模式之策略模式
什么是设计模式?为什么需要学习设计模式?
学习设计模式的目的是:为了代码可重用性、让代码更容易被他人理解、保证代码可靠性。设计模式使代码编写真正工程化;设计模式是软件工程的基石脉络,如同大厦的结构一样。
经典的设计模式有23种,但并不是每一种设计模式都被频繁使用。在这里,介绍最常用和最实用的几种设计模式,本文先来介绍策略模式(StrategyPattern)。
策略模式是一种行为设计模式,定义一系列算法,将每一个算法封装起来,并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化,也称为政策模式(Policy)。
假如正在开发一个在线商城的项目,每个产品都有原价,称之为originalPrice。但实际上并非所有产品都以原价出售,可能会推出允许以折扣价出售商品的促销活动。
商家可以在后台为产品设置不同的状态,然后实际售价将根据产品状态和原价动态调整。
具体规则如下:
部分产品已预售:为鼓励客户预订,将在原价基础上享受20%的折扣。
部分产品处于正常促销阶段:如果原价低于或等于100,则以10%的折扣出售;如果原价高于100,则减10元。
有些产品没有任何促销活动:它们属于default状态,并以原价出售。
这时需要写一个获取商品价格的函数getPrice,应该怎么写呢?
functiongetPrice(originalPrice,status){//...//返回价格;}事实上,面对这样的问题,如果不考虑任何设计模式,最直观的写法可能if-else多次条件判断语句来计算价格。
有三种状态,可以快速编写如下代码:
functiongetPrice(originalPrice,status){if(status==="pre-sale"){returnoriginalPrice*0.8;}if(status==="promotion"){if(origialPrice<=100){returnorigialPrice*0.9;}else{returnoriginalPrice-20;}}if(status==="default"){returnoriginalPrice;}}有三个条件,上面的代码写了三个if语句,这是非常直观的代码,但是这段代码组织上不好。
首先,它违反了单一职责原则(Singleresponsibilityprinciple,规定每个类或者函数都应该有一个单一的功能,并且该功能应该由这个类或者函数完全封装起来)。函数getPrice做了太多的事情,这个函数不易阅读,也容易出现bug。如果一个条件出现bug,整个函数就会崩溃。同时,这样的代码也不容易调试。
并且这段代码很难应对变化的需求,这时就需要考虑设计模式,其往往会在业务逻辑发生变化时展现出它的魅力。
假设业务扩大了,现在还有另一个折扣促销:黑色星期五。折扣规则如下:
价格低于或等于100元的产品以20%的折扣出售。
价格高于100元但低于200元的产品将减少20元。
价格高于或等于200元的产品将减少20元。
这个时候该怎么扩展getPrice?函数呢?
看起来必须在getPrice函数中添加一个条件语句:
functiongetPrice(originalPrice,status){if(status==="pre-sale"){returnoriginalPrice*0.8;}if(status==="promotion"){if(origialPrice<=100){returnorigialPrice*0.9;}else{returnoriginalPrice-20;}}//黑色星期五规则if(status==="black-friday"){if(origialPrice>=100&&originalPrice<200){returnorigialPrice-20;}elseif(originalPrice>=200){returnoriginalPrice-50;}else{returnoriginalPrice*0.8;}}if(status==="default"){returnoriginalPrice;}}每当增加或减少折扣时,都需要更改函数。这种做法违反了开闭原则(对扩展开放,对修改关闭)。修改已有的功能很容易出现新的错误,而且还会使得getPrice越来越臃肿。
那么如何优化这段代码呢?
首先,可以拆分这个函数getPrice?以减少臃肿。
/***预售商品价格规则*@param{*}origialPrice*@returns*/functionpreSalePrice(origialPrice){returnoriginalPrice*0.8;}/***促销商品价格规则*@param{*}origialPrice*@returns*/functionpromotionPrice(origialPrice){if(origialPrice<=100){returnorigialPrice*0.9;}else{returnoriginalPrice-20;}}/***黑色星期五促销规则*@param{*}origialPrice*@returns*/functionblackFridayPrice(origialPrice){if(origialPrice>=100&&originalPrice<200){returnorigialPrice-20;}elseif(originalPrice>=200){returnoriginalPrice-50;}else{returnoriginalPrice*0.8;}}/***默认商品价格*@param{*}origialPrice*@returns*/functiondefaultPrice(origialPrice){returnorigialPrice;}functiongetPrice(originalPrice,status){if(status==="pre-sale"){returnpreSalePrice(originalPrice);}if(status==="promotion"){returnpromotionPrice(originalPrice);}if(status==="black-friday"){returnblackFridayPrice(originalPrice);}if(status==="default"){returndefaultPrice(originalPrice);}}经过这次修改,虽然代码行数增加了,但是可读性有了明显的提升。getPrice函数显然没有那么臃肿,写单元测试也比较方便。
但是上面的改动并没有解决根本的问题:代码还是充满了if-else,而且当增加或者减少折扣规则的时候,仍然需要修改getPrice。
其实使用这些if-else的目的就是为了对应状态和折扣策略。
从图中可以发现,这个逻辑本质上是一种映射关系:产品状态与折扣策略的映射关系。
可以使用映射而不是冗长的if-else来存储映射,按照这个思路可以构造一个价格策略的映射关系(策略名称与其处理函数之间的映射),如下:
constpriceStrategies={"pre-sale":preSalePrice,promotion:promotionPrice,"black-friday":blackFridayPrice,default:defaultPrice,};将状态与折扣策略结合起来,价格函数就可以优化成如下:
functiongetPrice(originalPrice,status){returnpriceStrategies[status](originalPrice);}这时候如果需要加减折扣策略,不需要修改函数,只需要修改价格策略映射关系priceStrategies
之前的代码逻辑如下:
优化后的代码逻辑如下:
以上的优化策略就是使用了设计模式之策略模式,在实际的项目开发过程中还是比较实用。
在什么情况下可以考虑使用策略模式呢?如果函数具有以下特征:
判断条件很多
各个判断条件下的代码相互独立
然后可以将每个判断条件下的代码封装成一个独立的函数,然后建立判断条件和具体策略的映射关系。
原文:https://juejin.cn/post/7113451841001619463