关于前端:设计模式关于如何更好的封装与创建对象

上一节咱们次要学习了应用设计模式来写代码的指导思想以及设计模式的分门别类，本节次要学习创立型的三种设计模式是怎么应用的。如何利用创立型设计模式来领导咱们更好的封装代码更好的创建对象。

为什么要封装？封装能带给咱们什么益处？

• 定义变量不会净化内部：封装的首要目标是爱护咱们的变量不会被内部所净化，也不会净化内部的变量，在大型项目中很难保障变量名不和他人的变量名起抵触，所以说这点很重要。
• 可能作为一个模块调用：除了下面那点之外，良好的封装能力保障咱们的代码作为独立的模块与内部沟通，把程序变成模块架构中的根底就是良好的封装成模块。
• 遵循开闭准则：对批改进行敞开，对扩大进行凋谢，咱们的代码要容许使用者进行扩大而不容许使用者进行批改，开闭准则建设在封装的根底上，只有在良好的封装的状况下能力保障代码没法被进行间接批改。

什么是好的封装？

• 首先必须保障咱们的外部变量内部不可见，也不能批改，也不能间接拿到，
• 因为模块始终要和内部沟通，所以只是要让模块的外部变量不能被内部间接调用，因而咱们要留出两种接口，第一种是留出给内部调用性能的接口，
• 第二种是留出肯定的扩大接口，不便他人去扩大这个模块的代码和性能。

总结起来一共六个字： 不可见、留接口

一、封装对象时的设计模式

咱们要介绍三种帮忙咱们封装对象的设计模式，这三种设计模式能十分无效的帮忙咱们产出对象。为什么要在这里把对象和封装放在一起？起因是利用设计模式在产出对象的时候，其实曾经达成了一种比拟好的封装。

1.1. 创建对象时两种罕用的设计模式

工厂模式 ：既然叫做工厂，其实就是发明一个专门用来创建对象的工厂，咱们通过这个工厂来获取对象，从而代替咱们应用 new 操作符或者是代替咱们通过手写来生成对象。

目标 ：不便咱们大量创建对象。

利用场景 ：工厂必定是要大批量的产出某样货色，所以说当你须要创立的对象须要大批量生成时，应该首先想到工厂模式。比方咱们我的项目中有很多的弹窗，咱们应该把咱们弹窗组件封装成工厂模式提供给他人应用，当他人须要调用弹窗的时候只须要调用工厂就能拿到弹窗对象了。

建造者模式 ：工厂模式用来大量产出相似对象，这些对象可能只是内容不同，其它局部大致相同，而建造者模式截然相同，建造者咱们首先想到造房子，造房子必定是精细化建造，不可能大批量产出房子，所以说建造者模式其实是一种精细化构建的思维。

目标 ：领导咱们通过组合构建一个简单的全局对象

利用场景 ：当须要创立单个、宏大的可能并不需要大量产出的组合对象时，就能够思考应用建造者模式，它与工厂模式别离对应于编程中产出对象的两个方面。例如：写一个简单的轮播图，轮播图个别一个页面只有一个，而轮播图有各种各样的动画成果以及各种简单的交互，此时采纳建造者模式封装代码是十分好的。

以上是两个帮忙咱们创建对象的设计模式，在创立完对象之后往往须要一些特殊性的需要，例如：须要保障对象在全局有且仅有一个

1.2. 创立全局仅有一个对象的设计模式

单例模式 ：为什么要确保全局有且只有一个对象呢？因为在很多状况下，咱们为了避免出现多个对个对象之间产生烦扰，此时咱们往往须要保障全局只有一个对象。

目标 ：确保全局有且仅有一个对象

利用场景 ：为了防止反复新建，防止多个对象存在相互烦扰。例如：当在我的项目中反复的去 new 同一个类，会导致多个对象之间存在烦扰，这个时候能够思考应用单例模式。

二、根本构造

2.1. 工厂模式的根本构造

工厂模式就是写一个办法，只须要调用这个办法，就能拿到你要的对象，例如：

Factory 办法就是工厂模式要写的工厂，工厂要做的事件非常简单，通过参数（本例中为 type）通知工厂我要什么样的对象，在工厂外部依据参数判断要什么对象，而后在外部创立好对象并返回。

2.2. 建造者模式的根本构造

建造者模式是把一个简单的类各个局部拆分成独立的类，而后再在最终类里组合到一块，例如：

建造者模式突出建造，像咱们造房子一样，咱们会用预制好的板、梁这些预制好的货色来造成咱们的房子，因为建造者模式的内部结构比较复杂，所以在写建造者模式的时候它的外部会有很多别的类组成，就像下面代码所写的 Model1、Model2，能够把它们看做建房子的板和梁，最终拿出去给他人应用的类会由 Model1、Model2 在外部组合而成，也就是咱们说的把一个简单的类拆分成独立的类，而后再组合到一起造成最终应用的类，Final 为最终给进来的类。

2.3. 单例模式的根本构造

单例模式是通过定义一个办法，应用时只容许通过此办法拿到存在外部的同一实例化对象，例如：

单例模式的做法并不是很固定，更重要的是要记住它全局只有一个对象的思维，例如代码示例中的 Singleton 就是一个作为单例来实例化的一个对象，Singleton 对象下挂载一个 getInstance 办法，只能通过这个办法来获取这个类的实例化对象。这个办法外面先判断 this 上有没有 instance 属性，如果有间接返回这个属性，如果没有就把这个属性赋值为实例化的 Singleton 并返回。这样咱们通过调用 getInstance 办法来拿到实例对象，如果曾经实例化过了就会拿到之前实例化的对象，如果没有实例化过，就会把这个类实例化。

要实现一个规范的单例模式并不简单，无非是用一个变量来标记以后是否曾经为某个类创立过对象，如果是，则在下一次获取该类的实例时，间接返回之前创立的对象。

三、利用代码示例

3.1. 工厂模式的示例

3.1.1. 多彩的弹窗

需要：我的项目中有一个弹窗需要，弹窗有多种，它们之间存在内容和色彩上的差别。

如果咱们有一个 info 弹窗、一个 confirm 弹窗、一个 cancel 弹窗

如果咱们须要创立 3 个 info 弹窗、三个 confirm 弹窗、三个 cancel 弹窗，别离有不同的内容和色彩，在没有工厂模式的状况下，咱们很有可能会这样做：创立三个 Info 弹窗，new infoPop 而后传入内容和色彩，而后复制粘贴一大堆，这样写就很麻烦。如：

咱们用工厂模式革新一下

创立一个 pop 工厂，而后传入弹窗类型，内容和色彩参数，在工厂外面判断要什么类型的弹窗就返回什么类型的弹窗。这样创立工厂之后咱们再去创立弹窗对象只须要通知工厂须要什么类型的弹窗即可。

代码写成这样之后就能够把这部分代码作为插件的代码封装起来，封装很简略，把代码放入匿名自执行函数中，而后指向内部裸露工厂即可（挂载在全局对象下），内部的使用者就能够间接调用工厂而不必关怀具体要 new 哪个弹窗。

如果有很多个弹窗就能够把弹窗配置成数组，数组中定好要什么弹窗，弹窗的内容和色彩，而后循环数组调用工厂即可。

下面的弹窗工厂还存在一个问题，如果使用者在不晓得的状况上来 new 了这个工厂，这样可能就不太好使了，所以咱们革新一下工厂，判断 this 是不是弹窗工厂 pop，如果是就代表使用者应用了 new 操作符，此时就给它 new 一个实例，实例为 thistype，如果不是就代表使用者是间接调用的，就去 new 一下弹窗工厂 pop，让它再走到流程中去。

此时就不必 switch 去进行判断了，能够把 switch 代码都删掉，把 infoPop、confirmPop、cancelPop 这些办法都挂载到 pop 工厂的 prototype 下面去。

这样无论当前再要扩大不同类型的弹窗也好，还是须要缩小弹窗也好都会不便很多，因为咱们只须要批改一下原型链即可，而对于之前这种 switch 的写法，咱们须要批改一下 switch 还要加一层判断，换成这种写法咱们只须要批改 prototype 就能够了。这种就是加了健壮性判断和可扩展性的工厂代码。

3.1.2. 源码示例 -jQuery

需要：jQuery 须要操作 dom，每一个 dom 都是一个 jQuery 对象。

jQuery 把 dom 包装成 jQuery 对象来不便咱们操作 dom，咱们要操作这么多 dom，如果每一个 jQuery 对象都须要 new 的话，这样的操作就非常麻烦，所以说 jQuery 自身的封装采纳的是工厂模式，咱们只须要调用 jQuery 的 $ 办法就能拿到 jQuery 对象，jQuery 的源码外部是怎么结构这个工厂的？

首先在外层以一个匿名自执行函数将代码封装起来，而后在自执行函数外部定义一个裸露进来的 jQuery 办法，它接管一个选择器以及上下文，再把 jQuery 办法作为一个 $ 符号和 jQuery 挂载到 window 对象上，也就是把工厂挂载到 window 上。

jQuery 工厂外部返回了一个 jQuery.fn 下的 init 办法，也就是说其实拿到的对象是通过 jQuery.fn.init 创立的实例对象，这里之所以不去 new jQuery 类自身，是因为会造成有限循环的递归。

而后让 jQuery.fn 等于 jQuery.prototype，因为所有的办法都会挂载到 prototype 下，这里利用援用的特点让 fn 等于 prototype，援用了 prototype 上所有的办法。而后在 prototype 下创立 init 办法。

既然咱们最终拿到的实例化对象是 init 的实例化对象，所以说 init 类的原型链要和 jQuery 自身的原型链等价，所以再把 jQuery.fn.init.prototype 等于 jQuery.fn，也就相当于等于 jQuery 的 prototype

绝对于 jQuery 的整个架构而言，它的各种各样的办法和模块是怎么扩大的呢？

它有一个 extend 办法，这个办法的作用是拷贝，如果只传一个对象它会把这个对象拷贝到 jQuery 下面

代码示例中拷贝到 jQuery 的 fn 下面也相当于拷贝到它的原型链下面，也相当于拷贝到了 init 的原型链下面，而后各种各样的模块就能够通过 extend 拷贝进去。比方 css 办法、animate 办法等等都会通过这个办法拷贝进去。

以上就是 jQuery 架构上的实现，其实就是一个工厂模式，只不过它去结构工厂的形式和咱们后面演示的代码有点差异，但它始终逃不出一点就是用调用办法的形式主动给咱们想要的对象来代替咱们去 new 想要的对象。这样带来的益处第一个就是不便咱们操作，像 jQuery 中大量操作 dom 的状况下没必要一个个去 new 它，第二个就是咱们能够没必要去具体理解要 new 哪个，只须要通知工厂须要哪个就能够了。

通过以上两个案例，不难发现工厂模式就是把真正须要裸露的对象先封装起来，而后只裸露一个工厂办法，让使用者通过这个工厂办法来获取对象，它的劣势在于不便咱们大量创建对象。

3.2. 建造者模式的示例

3.2.1. 编写一个编辑器插件

需要：有一个编辑器插件，初始化的时候须要配置大量参数，而且外部性能很多。（搭建架子，细节不实现）

编辑器插件的性能很多，比方咱们能够后退后退、编辑字体色彩等等性能，面对这样一个简单的编辑器插件，咱们应用建造者模式是十分适合的，因为咱们要写的编辑器插件：

1. 只须要大量的编辑器对象，通常来说一个编辑页面只须要一个编辑器；
2. 它初始化的时候须要大量参数，这样大量的参数让工厂去解析的话会破费大量的工夫；
3. 它的外部性能比较复杂，可能由多模块组成。这时候咱们就须要一个精细化构建—建造者模式。

编辑器会有一个最终的类，也就是说应用的时候须要 new 这个类（本例为 Editor 类），建造者模式是把它的模块拆分成独立的类而后再组合起来，要实现咱们的性能，须要拆分出哪些类？

• 首先须要一个初始化的类，因为咱们的编辑器插件要有 html 构造，所以咱们创立 initHTML 类；
• 而后创立管制字体大小、色彩的类 fontControll；
• 咱们还有后退后退性能，这个时候就须要一个状态治理类来治理以后内容是什么状态，所以创立状态治理类 stateControll

模块都拆出来之后，再去给这些类定义方法

• 比方 initHTML 类上会有 initStyle 办法初始化编辑器的款式，会有最终将编辑器渲染成 dom 的 renderDom 办法
• 比方 fontControll 类上会有扭转字体色彩的办法 changeColor，扭转字体大小的办法 changeFontSize
• 比方状态治理类 stateControll 上要有保留状态的办法 saveState、回滚状态的办法 stateBack、后退状态的办法 stateGo

咱们把最终给他人应用的类 Editor 挂载到 window 对象上

而后将拆分进去的类在 Editor 类中组合起来

当咱们把这些独立的模块都构建进 Editor 类之后，这些模块就都能够相互调用了。比方咱们当初减少一个状态回滚的性能，咱们只须要拿出以后状态。

首先在 stateControll 类中定义一个 state 数组专门用来存储后退以及后退的状态，而后创立状态指针，指向以后的状态

在状态回滚办法 stateBack 中，只须要从状态数组外面取出以后状态的上一个状态，而后调用字体管制模块 fontControll 扭转字体

在这样的一种组织之下，各种模块之间的沟通会变得很清晰，一个简单性能的插件被咱们解析成了几个独立的小插件，最初再组合起来，这样既不便咱们编写代码，也不便咱们去组织模块之间的沟通。 放弃了模块间的低耦合，从而造成高效沟通和高效编程，这就是建造者模式的目标。

3.2.2. Vue 的初始化

需要：vue 外部模块泛滥，而且过程简单，有须要能够本人去浏览源码。

Vue 外部的建造形式也能够看成是建造者模式，它的建造过程如下：

首先创立 Vue 类，为了避免使用者不通过 new 操作符调用它，须要在它的外部应用 instance 进行判断 this 是不是 Vue，如果不是代表没有应用 new 操作符，此时须要抛出正告通知使用者没有应用 new 操作符，如果是则调用 init 办法，将用户在初始化的时候后传入的配置参数 options 传进去实现一个配置的初始化。

vue 相干的很多性能比方生命周期、事件零碎、渲染函数、都是怎么注入到这个极其简略的 Vue 类中的呢？

vue 源码中调用了一系列的初始化办法进行混入，例如：

通过调用这些办法混入到 Vue 类，和上例中将模块独立为一个个类最初放到 Editor 类中是一样的情理，只不过 Vue 中将写法改成了办法调用，而上例中间接在构造函数中写入。

Vue 类自身非常简单，它所有的性能都是独立开发而后通过一系列的混入实现的，由此可见 Vue 应用的也是建造者模式来构建对象的。

3.3. 单例模式的示例

3.3.1. 写一个数据贮存对象

需要：我的项目中有一个全局的数据存储者，这个存储者只能有一个，不然会须要进行同步，减少复杂度。

在一个多方工作的状况下如果有使用者不小心又 new 了这个对象，就会导致数据可能会产生两边的不统一，就须要同步这些数据，无形之中减少了复杂度，这样一个全局贮存对象必然要变成单例模式。

假如咱们的全局贮存对象为 store，首先创立 store 类，而后在外部创立 store 变量用于存储数据，咱们须要保障无论怎么 new store 类只能返回同一个对象，能够通过 store 下的 install 属性来判断，如果有这个属性就间接返回该属性，如果没有就把 store.install 属性赋值为 this，this 在应用 new 操作符的时候就指向 store 自身。而后咱们在 store 类的内部将 install 属性初始化为 null，代码示例如下：

通过以上代码能够发现，无论怎么 new store 类拿到的都是同样的对象，例如：

代码示例中创立了两个 store，因为它们都指向同一个对象，当批改 s1 的属性时，s2 的属性也扭转了

此时如果去掉单例模式验证一下，将 store 类的代码批改为：

运行后果如下：

此时因为每次 new 都会创立新的对象，所以 s1 和 s2 不指向同一个对象，导致数据要保护两份，单例模式的目标就是缩小多个对象的烦扰，使咱们编程更加简略。

3.3.2. vue-router 源码解析

需要：vue-router 必须保障全局有且仅有一个，否则会错乱。

vue-router 源码里怎么保障全局只有一个的？代码如下：

下面代码就是避免 vue-router 反复注册的代码，咱们在应用 vue-router 的时候会调用 vue.use 办法去注册 vue-router，其实在调用 vue.use 的时候就会去执行 install 办法，所以只有保障 install 办法每次在调用的时候判断一下是否曾经被 use 过了，如果曾经 use 过了就不执行前面的代码。

它的实现形式也很简略，在外层定义一个_Vue 变量，install 办法每次都会接管到一个参数 Vue，这个参数就是 Vue 的类，而后外部判断了 install 办法上面有没有 installed 属性并且_Vue 等于 Vue 类，就间接 return 不执行前面的内容。如果没有 installed 属性就阐明没有被赋值过，将 installed 属性设为 true，再将里面定义的_Vue 变量赋值为 Vue 类，这样在下次调用 install 办法的时候就间接进入判断条件中断执行了。这跟咱们后面演示的单例模式十分相似，都是通过办法的一个属性来判断，vue-router 中额定加了一个判断也就是内部的_Vue 变量是否等于传进来的 Vue 类，通过多重判断保障代码安全性。

下一篇：设计模式—对于如何进步代码复用

本文由博客一文多发平台 OpenWrite 公布！