共计 7907 个字符，预计需要花费 20 分钟才能阅读完成。
上一节次要学习创立型的三种设计模式是怎么应用的。如何利用创立型设计模式来领导咱们更好的封装代码更好的创建对象，本节次要学习怎么利用设计模式来进步代码复用性。
进步可复用性的目标？
为什么要进步可复用性？进步可复用性能带来什么益处？
- 遵循 DRY 准则：英文是 dont repeat yourself，这个准则的意思是说要时刻记住去查看你代码之中是否有反复的代码，如果有，把它作为一个公共局部形象进去。
- 缩小代码量，节俭开销：遵循了 DRY 准则之后咱们的代码量就会缩小，内存开销也会逐步缩小，因为没有反复的代码块了。
什么是好的复用？
- 在对象这个层面，一个可复用性高、设计的好的代码它的对象都是能够重复使用的，咱们毋庸去频繁的批改对象来让它合乎新的需要，它面向形象而不面向具体。
- 对于进行同样操作的代码块不会反复写很屡次。
- 高复用性的代码必然是建设在一个模块低耦合的根底之上的，尽量做到模块之间的性能繁多，模块越繁多，这个模块就能越容易被复用。
一、进步复用性的设计模式
1.1. 缩小反复代码数量，高效复用代码的设计模式
桥接模式：它和 DRY 准则十分类似，都是把公共局部拿进去而不是耦合在现有的代码当中，通过把公共局部提取进去而后再桥接到应用的中央来缩小代码耦合。
目标：通过桥接代替耦合
利用场景：缩小模块之间的耦合
享元模式：通过观察类似的代码块和对象之间的共同点和不同点，辨别出私有局部和公有局部，而后把私有局部作为一个享元抽取进去，从而缩小对象或者代码块。
目标：缩小对象 / 代码数量
利用场景：当代码中创立了大量相似对象和相似的代码块时就能够采纳享元模式
1.2. 创立高可复用性代码的设计模式
模板办法模式：定义一个操作中的算法的框架，而将一些步骤提早到子类中。使得子类能够不扭转一个算法的构造即可重定义该算法的某些特定步骤。
目标：定义一系列操作的骨架，也就是说不要去具体实现操作，先把操作的骨架定下来，前面的相似操作就以这个骨架为根底，在骨架上进行扩大和具象化来实现前面具体的需要，简化前面相似操作的内容
利用场景：当你在我的项目中呈现了很多相似的操作，它们可能根本的骨架是一样的，然而这些操作又具备本人的特点，这个时候咱们能够应用模板办法模式
二、根本构造
2.1. 享元模式的根本构造
需要：有一百种不同文字的弹窗，每种弹窗行为雷同，然而文字和款式不同
这种状况咱们没必要去新建一百个弹窗，咱们能够创立一个弹窗类，这个弹窗类保留雷同的行为，而后把显示弹窗这个行为形象为一个办法，这个办法再接管到底要显示什么样的弹窗；它们不同的中央是文字和款式，所以咱们能够把它们不同的中央提取进去作为数组对象进行配置，而后咱们只须要创立一个弹窗实例，通过循环数组调用弹窗实例的显示办法，传入每个弹窗的文字和款式即可。代码如下：
享元模式说白了就是当咱们察看到对象或者代码块存在多个相似之处时，将它们雷同的局部保留，不同的局部提取进去作为享元，这样咱们就能用一个对象来代替多个对象。享元模式的外围是使用共享技术来无效反对大量细粒度的对象。
2.2. 桥接模式的根本构造
需要：有 3 种形态，每种形态都要显示三种色彩
在这样的状况下如果咱们不去留神可复用性，很有可能就会创立 9 种不同色彩的不同形态。咱们能够察看一下：3 个形态它们可能没有什么共同点，然而色彩有共同点，所以咱们能够把它们的色彩提取进去作为专用办法，这些形态的类都依赖于这个办法，通过这个办法来展现色彩，这样咱们只须要三个类即可实现需要。比方咱们须要红色的圆形，只须要 new 一个圆形类通知它须要红色即可。
桥接模式总结来说就是把这些反复的局部抽取进去作为一个专用的办法，而后再把它桥接回去，它有点相似建造者模式，先拆分而后再组合，但建造者模式的外围关注点是如何去构建对象（关注创立），而桥接模式关注的是如何通过一个桥接的形式来简化代码，进步代码可复用性（关注性能）。
2.3. 模板办法模式的根本构造
需要：编写导航组件，有的带音讯提醒，有的是竖的，有的是横的，前面可能还会新增其它类型
对于这种需要，咱们没必要针对每一个导航组件都去新建一个类，能够写一个根底的组件类，具体的实现提早到具体应用的时候，代码示例：
代码示例中，先新建根底类 baseNav，在根底类中定下根本骨架，包含它的行为也是一样的解决，先写出它的根底行为，而后留出一个回调，等到具体决定要做音讯提醒型的还是其它类型的时候再通过回调来实现不同的中央，实现具体的操作和行为。
三、利用示例
3.1. 享元模式的示例
3.1.1. 文件上传
需要：我的项目中有一个文件上传的性能，该性能能够上传多个文件。
先看一个没有应用享元模式的代码示例：
下面代码中，在没有应用享元模式的状况下，咱们要上传四个文件，就须要 new 四个 uploader 类别离指定文件，如果咱们应用享元模式优化这段代码：
- 提取私有局部和公有局部：咱们察看一下，对于这四个对象而言，它们的公有局部是要上传的文件和文件类型是不同的，而私有局部是每个对象都具备初始化、删除、上传的性能办法，享元模式就是把这四个对象的公有局部作为公共的享元提取进去，所以咱们写一个数组，将这几个对象的公有局部储存起来
而后将私有局部都保留下来，所以说下面 prototype 上的 init 办法、delete 办法、uploading 办法都能够抄下来保留，而 uploader 类中的属性就能够删掉不须要了，咱们把上传的文件、文件类型都作为参数传入 uploading 办法中
这么一革新之后，咱们只须要实例化一次 uploader，而后循环数组调用实例对象的 uploading 办法，传入文件和文件类型即可。
再次总结享元模式：享元模式到底怎么用？其实就是去察看代码中反复的局部，去看一下它们有哪些局部是公有的，哪些局部是私有的，而后把公有的局部提取进去作为专用的享元，享元的模式不肯定非要是数组，它能够是对象也能够是办法等等。这种思维就像咱们生存中一个很简略的情理，咱们要试穿一百套衣服，没必要去请一百个模特，咱们能够请一个模特别离试穿这一百套衣服。
3.1.2. jQuery 中的 extend
需要：extend 办法，须要判断参数数量来进行不同的操作。
jQuery 的 extend 办法如果给它一个参数，比方给个对象，就会把这个对象扩大到 jQuery 下面去，如果给它两个对象，它会将这两个对象合并之后返回进去，例如：
对于这样的操作，咱们可能会想到先写一个 extend 办法，而后在办法外部通过 argument 对象去判断参数的数量，依据 argument 不同的长度去进行不同的操作，如：
这样的代码从原则上来说没有谬误，然而能够发现这两段 for in 循环是极其类似的，DRY 准则通知咱们要尽量减少反复的代码，所以咱们应用享元模式来优化一下代码
- 提取私有局部和公有局部：这两段类似的代码它们的公有局部是接管拷贝的指标和拷贝的起源是不同的，咱们先把它们的不同点提取为内部的私有享元，把接管拷贝的指标（extend 第一个参数）作为内部的享元，通过 target 存起来，而后把拷贝数据的起源也就是被拷贝者变成 source 变量
它们私有的局部是 for in 循环，所以咱们保留 for in 循环，for in 循环应该循环咱们的 source，而后把 sourse 拷贝到 target 下面
这里仍然要进行 if else 判断，判断如果参数长度等于 1 阐明是给 jQuery 对象自身扩大属性，就扭转一下咱们的享元，将 target 变成 this，而后将 sourse 变成 argument 第一项；如果参数长度不等于 1 的话就阐明要将第二个参数对象拷贝到指标参数也就是第一个参数上，所以将 target 赋值为 argument 的第一项，将 source 变成 argument 第二项
（代码勘误：以上 if 判断应该是 arguments.length == 1）
这样就胜利的把两段 for 循环代码缩小为一段，通过将不同的局部提取进去作为内部专用享元，而后只保留一段专用的操作，通过判断来扭转内部的专用享元应该是哪个指标，无效的缩小了反复代码，这就是享元模式的妙用。
3.2. 桥接模式的示例
3.2.1 创立不同的选中成果
需要：有一组菜单，下面每种选项都有不同的选中成果。
假如咱们有三个菜单 menu1、menu2、menu3，在惯例状况下咱们会先新建一个菜单类，它接管一个文字内容，把文字内容放到类属性下面，而后创立 div，将 div 的内容设置为文字内容，如：
在应用的时候会创立 menu1、menu2、menu3 三个实例，将对应的内容传进去。
而后给它们绑定不同的事件实现不同的成果
在不应用桥接模式的状况下，咱们要创立三个对象，别离对这三个对象绑定不同的事件去扭转色彩，这样的代码反复率比拟高，不合乎高复用性准则。
应用桥接模式优化下面的代码：
- 提取公共局部：下面代码的公共局部是设置色彩和事件绑定这块，咱们将这块提取进去而后桥接到源对象上：先在 menuItem 类中退出一个 color 属性，再接管一个 color 参数（它是咱们要桥接的对象），而后将接管的 color 参数桥接到 menuItem 类的 color 属性上
而后创立 menuColor 类，它接管两个参数 colorover（鼠标悬停的色彩）、colorout（鼠标移开的色彩）、别离把接管的两个参数放在 menuColor 类的属性上
因为 dom 曾经放在 menuItem 类的属性上了，所以咱们能够通过一个办法来把 dom 事件绑定下来，咱们给 menuItem 类的 prototype 增加一个 bind 办法，它负责给 dom 绑定事件
绑定事件后咱们不须要关怀它到底要用哪个色彩，只须要间接拿出桥接过来的色彩对象 (this.color) 就能够了，所以咱们在事件绑定的外层创立 self 变量赋值为 this，因为事件中的 this 指向 dom 对象，所以只须要在 onmouseover 事件中将 this.style.color 赋值为菜单对象也就是 self.color 对象上的 colorOver 属性即可，onmouseout 事件中同理。
这样再去实现需求时，咱们只须要定义一个内部数据数组，这个内部数据定义了菜单的文字、悬停和移出的色彩，应用时循环这个数组创立 menuItem 实例，传入数据的内容，而后创立咱们要桥接过来的色彩对象通知它悬停和移除的色彩是什么，并将这个对象传入 menuItem 实例。最初调用 bind 办法将事件主动绑定下来。
通过比照能够发现咱们的反复代码变得更少了，代码的复用性更好了，这就是桥接模式的作用。面临这样的问题时，咱们通过把它们的变动局部和不变局部拆散，再桥接到一起来应答前面多维度的变动，这就是桥接模式的目标和它带来的益处。
3.2.2. Express 中创立 get 等办法
需要：express 中有 get、post 等等办法，有七八个，如何不便疾速的创立。
比方咱们能够在 express 中通过 app.get 来设置一个 get 申请的中间件、通过 app.post 来设置一个 post 申请的中间件、能够通过 app.delete 来设置一个 delete 申请的中间件，咱们要给这个实例 app 赋予这些办法
先看一个背面示例：
很多人会这样动手，创立一个 express 类，给它的 prototype 上增加 get、post、delete 办法
这是一个很典型的咱们的零碎可能会朝着多维度倒退的例子，因为前期可能还要增加 put 等等申请形式，这些申请形式之间有十分类似的局部，这样就会反复的往原型链上增加办法，造成很多反复代码，如何去优化呢？
express 源码中是这样做的，它首先会有一个 methods 数组，这个数组在源码中是通过一个第三方库而后 require 进来的，演示代码中咱们就间接创立这个数组，将几个有代表性的申请办法名称写入数组，而后循环这个数组，在循环体内给 express 实例去注册这些办法
这样咱们就不必反复写那么多办法了，对于具体的性能，它借助一个 route 对象将性能桥接过来，间接在注册的办法外面调用 route[method]而后传入参数
route 外面也是相似的一个循环，把源码拷过去
能够看到 route 外面的 methods 也是通过一个循环来注入的，循环外部依据咱们是什么样的办法进行对应的操作，调用对应的中间件，这样就十分无效的缩小了反复代码，进步了代码的可复用性
这种做法相当于间接调用 get 或者 post，而后这个 get 和 post 利用桥接过来的 route 对象上的办法来实现性能，而 route 对象上的办法也是通过桥接来实现的，在 route 外部桥接的其实就是下面源码中一整段的 function，在这个 function 中来判断办法是什么，调用对应办法的中间件
以上就是桥接模式在 express 中优化代码的利用。
3.3. 模板办法模式的示例
3.3.1. 编写一个弹窗组件
需要：我的项目有一系列弹窗，每个弹窗的行为、大小、文字都不雷同。
如果咱们写一个音讯型弹窗、发送申请型的弹窗、删除操作型的弹窗
以惯例的思维咱们可能会新建一个音讯型弹窗类、发送申请型的弹窗类、删除操作型的弹窗类，这种形式大可不必，尽管它们之间的行为、大小等不同，然而它们之间有十分多的共同点，比如说它们始终是一个弹窗、它们要弹出、点击确定或者勾销它们都要隐没等，这是它们的共同点，参照模板办法模式的思维，把他们的共同点先提取出一个根底模板类，根底模板类中定义 word、size、dom 属性，别离赋值为传入的 word 和 size，dom 初始化为 null
而后定义根底的行为办法如显示弹窗的初始化，在办法体内创立 div，把 div 的文字赋值为 this.word，div 的款式赋值为 size 的属性，这是每个弹窗都有的，它必须有肯定的宽高和文字，再把 this.dom 赋值为这个 div
而后定义基本操作的办法比方所有的弹窗点击勾销之后都要暗藏，办法体内让 div 的 display 变为 none
当然咱们还有确定操作，然而咱们没方法确定点击确定之后它要干什么，所以咱们先定下确定操作的根底行为，点击确定首先也要暗藏弹窗
而后咱们再定义一个非凡型弹窗，比如说定义一个 ajax 型的弹窗，点击确定之后要发送一个 ajax 申请。咱们创立一个 ajaxPop 类，这个 ajaxPop 类继承根底类 basePop（类的外部通过 call 调用其余类能够实现继承）
再扩大 ajaxPop 类的行为，将根底类的实例赋值给 ajaxPop 类的 prototype 即可继承根底类的行为
而后获取 ajaxPop 类之前的暗藏行为，再定义它新的暗藏行为办法，在新的办法外面先调用之前的暗藏行为办法，再去退出 ajaxPop 类非凡的暗藏行为，比方它点击勾销之后要打印 1（装璜者模式的体现）
确认型弹窗同理，先把之前的确认行为拿进去，而后再重写它的确认行为，在重写的办法体内调用之前的确认行为，再退出非凡的确认行为，比方要发送一个 ajax 申请。（装璜者模式的体现）
这样的形式下咱们就能够十分好的以起码的代码量去创立和扩大不同类型的弹窗，这种形式和面向对象中的继承很相似，模板办法模式并不一定要通过继承来实现，有十分多的实现形式，它强调的并不是肯定要有继承和模板，而是强调先定义前面须要进行的一系列不同维度的操作的根本行为，而后在这个根本行为的操作上给出一个扩大的空间，这就是模板办法模式的目标和作用。
3.3.2. 封装一个算法计算器
需要：当初咱们有一系列本人的算法，然而这个算法常在不同的中央须要减少一些不同的操作。
比方它在 a 页面须要在计算之前让两个数相加，在 b 页面须要在计算之前让两个数相减，也就是说这个算法计算器有一系列的根本算法，这些根本算法又在不同的中央有不同的操作，这种需要就是十分典型的能够用模板办法模式来解决的例子。代码示例：
首先咱们创立一个 counter 类
定义一下 counter 办法的根底计算也就是先把算法骨架搭进去，在 prototype 上增加 count 办法，这个 count 办法就是计算的时候调用的办法，它会接管计算的数据
咱们在这个办法外面先去定义一个根本办法 baseCount，假如 baseCount 先把 num+4，再把 num*4
这样咱们定义好了根底计算，模板办法模式是先定义好根底，而后再去扩大，怎么去扩大根底计算？
所以咱们须要留出两个扩大办法，比照上一个案例弹窗所演示的继承形式，这里咱们能够用办法组合的形式来实现扩大。
先在 counter 类的 prototype 上定义两个办法，一个是根底算法计算之前要进行的计算，一个是根底算法计算之后要进行的计算
这两个办法相似 axios 的申请拦截器和响应拦截器，通过 addBefore 和 addAfter 增加一些办法，这些办法别离会在 baseCount 调用之前和之后来进行作用，所以咱们须要在 counter 类中减少两个队列，用于寄存根底算法计算之前增加的办法和之后增加的办法。
而后别离在 addBefore 和 addAfter 办法外面 push 对应的办法
有了扩大的办法之后咱们须要改写一下计算方法，让它先执行 beforeCounter 队列，计算之后再执行 afterCounter 队列。
count 办法内先定义变量_resultnum，初始等于传进来的 num，而后定义一个_arr 变量，先将_arr 初始化为[baseCount]，这个_arr 就是咱们要执行的办法队列
而后咱们将 beforeCounter 拼接_arr 再拼接上 afterCounter，这样整个调用就造成了一个队列 beforeCounter => baseCount => afterCounter
接下来咱们只须要从头到尾顺次执行这个队列，传入数据进行计算，再将后果给_resultnum，所有的办法都执行完后再将最终的计算结果_resultnum 返回进来就能够了
代码写好之后，应用起来就非常简单了，假如在 a 页面根底计算之前先减减，根底计算之后再把数字乘以 2，咱们能够先新建一个实例化对象，调用它的 addBefore 办法，回调函数中进行减减操作再把计算结果返回；再调用 addAfter 办法，回调中将后果乘以 2 并返回；再去调用咱们的根底计算方法 count 把须要计算的数字传入即可。
这样就保障了 a 页面既有咱们的根底算法，又有它的特异性算法。
下面的弹窗例子中应用的是继承的形式，本例中应用组合的形式，把咱们要扩大的货色变成办法组合到一起来达成扩大，无论应用哪种形式它们都是去找到类似的局部，而后定义根本的操作骨架，依据操作骨架再给出扩大接口，这就是模板办法模式的核心思想。再次强调无论什么设计模式，咱们肯定要先记住它的核心思想，而不是记住它的行为。
最初，咱们来认识一下JavaScript 的组合和继承
- 组合
① JavaScript 最后没有专门的继承，所以最后的 JavaScript 推崇函数式编程，而后进行对立组合桥接到一起
② 桥接模式能够看成组合的一种体现，它把不同的货色组合到一起来产生一个新的对象或残缺的性能，组合的益处是耦合低、复用办法不便、扩大不便，它的毛病就是要手动的去一个个组合，不能像继承一样主动实现
- 继承
① 在 ES6 呈现 class 和 extend 之前，继承也能够实现，实现的形式多种多样，但都是各有弊病
② 模板办法模式能够看成继承的一种体现，继承的益处是能够主动取得父类的内容与接口，不便统一化，继承的毛病就是不不便扩大，如果用子类去继承父类，父类产生更改的时候子类也会产生更改，这样就十分不利于后续的扩大
通常来说组合大于继承，咱们更推崇于应用组合来代替继承，能应用组合解决问题的话最好不要应用继承。
下一篇：设计模式—对于进步可扩展性（办法层面）的学习（更加从容的应答需要变更）
本文由博客一文多发平台 OpenWrite 公布！
