前言

在你的第一印象中,设计模式应该是什么呢

JavaScript 发展的历程中,前行者们从实践中总结出了很多特定问题的解决方法。简单来说,设计模式就是在某种场合下对特定问题的简洁而又优雅的解决方案

在之后的一段时间,我将记录 JavaScript 中各种常见的设计模式。或许你对此已经驾轻就熟,或许平时已在使用,但是对其概念并不是特别熟悉,又或许只是对此有一些模糊的概念。那么,相信这个系列一定会带给你些许收获

在了解这些常见的模式之前,默认你已经至少掌握

  • this
  • 闭包
  • 高阶函数
  • 原型和原型链

了解它们,会让你更加清晰的认识一个模式。当然,或许我之前所记录的有关这方面的东西能够给你些许帮助 传送门

如果文章中有出现纰漏、错误之处,还请看到的小伙伴多多指教,先行谢过

下面,就让我们从它开始吧 — 单例模式

概念

顾名思义,只有一个实例

看到这样的定义,你的脑海中是否会冒出 全局变量 的概念呢。不可否认,全局变量是符合单例模式的概念的。但是,我们通常不会也不应该将它作为一个单例来使用,原因有以下两点:

  • 全局命名污染
  • 不易维护,容易被重写覆盖

ES6 之前,我们通常会使用一个构造函数来模拟一个类,现在我们也可以直接使用 class 关键字来创建一个类,虽然其本质也是原型

想要保证一个类仅有一个实例,我们需要提供一个变量来标志当前是否已经为一个类创建过实例。所以,单例模式的核心就是:确保只有一个实例,并提供全局访问

围绕这个核心,我们也就基本清楚了单例模式的实现方式

实现

基础版

根据单例模式的定义,我们可以用以下方式简单实现

var Singleton = function(name){
this.name = name
}
Singleton.instance = null // 初始化一个变量
Singleton.getInstance = function(name) {
// 判断这个变量是否已经被赋值,如果没有就使之为构造函数的实例化对象
// 如果已经被赋值了就直接返回
if(!this.instance) {
this.instance = new Singleton(name)
}
return this.instance
}
var a = Singleton.getInstance('Tadpole')
var b = Singleton.getInstance('Amy')
a === b // true

以上代码,清晰的反映出了单例模式的定义。通过一个中间变量的方式,只初始化一个实例,所以最终 ab 是完全相等的

我们也可以用 ES6class 关键字来实现

class Singleton {
constructor(name){
this.name = name
this.instance = null
}
// 提供一个接口对类进行实例化
static getInstance(name) {
if(!this.instance) {
this.instance = new Singleton(name)
}
return this.instance
}
}

不难发现,ES6 的实现方式和我们通过构造函数的方式实现基本是一致的

存在问题:

  • 不够 透明,我们需要约束类实例化的调用方式
  • 耦合度过高,功能业务代码耦合在一起不利于后期维护

构造函数

让我们对上面的方式做一个简单的修改

// 将变量直接挂在构造函数上面,最终将其返回
function Singleton(name) {
if(typeof Singleton.instance === 'object') {
return Singleton.instance
}
// 正常创建实例
this.name = name
return Singleton.instance = this
}
var a = new Singleton('Tadpole')
var b = new Singleton('Amy')

解决了基础版类不够 透明 的问题,可以使用 new 关键字来初始化实例,但同时也存在着新的问题

  • 判断 Single.instance 类型来返回,可能得不到预期结果
  • 耦合度过高

这种方式也可以通过 ES6 方式来实现

// 将 constructor 改写为单例模式的构造器
class Singleton {
constructor(name) {
this.name = name
if(!Singleton.instance) {
Singleton.instance = this
}
return Singleton.instance
}
}

闭包

通过单例模式的定义,想要保证只有一个实例并且可以提供全局访问。那么,闭包肯定也是可以实现这样的需求

var Singleton = (function () {
var SingleClass = function () {};
var instance;
return function () {
if (!instance) {
instance = new SingleClass() // 如果不存在 则new一个
}
return instance;
}
})()

通过闭包的特性,保存一个变量并最终将其返回,提供全局访问

同样的,以上的代码还是没有解决耦合度的问题

让我们仔细观察这一段代码,如果我们将其中构造函数的部分提取到外部,是否就实现了功能的分离呢

代理实现

修改一下上面的代码

function Singleton(name) {
this.name = name
}
var proxySingle = (function(){
var instance
return function(name) {
if(!instance) {
instance = new Singleton(name)
}
return instance
}
})()

将创建函数的步骤从函数中提取出来,把负责管理单例的逻辑移到了代理类 proxySingle 中。这样做的目的就是将 Singleton 这个类变成一个普通的类,我们就可以在其中单独编写一些业务逻辑,达到了逻辑分离的效果

我们现在已经达到了逻辑分离的效果,并且也不 透明 了。但是,这个负责代理的类是否已经完全符合我们的要求呢,答案是否定的。设想一下,如果我们的构造函数有多个参数,我们是不是也应该在代理类中体现出来呢

那么,有没有更通用一些的实现方式呢

通用惰性单例

在前面的几个回合,我们已经基本完成了单例模式的创建。现在,我们需要寻求一种更通用的方式解决之前留下来的问题

试想一下,如果我们将函数作为一个参数呢

// 将函数作为一个参数传递
var Singleton = function(fn) {
var instance
return function() {
// 通过apply的方式收集参数并执行传入的参数将结果返回
return instance || (instance = fn.apply(this, arguments))
}
}

这种方式最大的优点就是相当于缓存了我们想要的结果,并且在我们需要的时候才去调用它,符合封装的单一职责

应用

前面有说过,所有的模式都是从实践中总结而来,下面就让我们来看看它在实际开发中都有哪些应用吧

通过单例模式的定义我们不难想出它在实际开发中的用途,比如:全局遮罩层

一个全局的遮罩层我们不可能每一次调用的时候都去创建它,最好的方式就是让它只创建一次,之后用一个变量将它保存起来,再次调用的时候直接返回结果即可

单例模式就很符合我们这样的需求

// 模拟一个遮罩层
var createDiv = function () {
var div = document.createElement('div')
div.style.width = '100vw'
div.style.height = '100vh'
div.style.backgroundColor = 'red'
document.body.appendChild(div)
return div
}
// 创建出这个元素
var createSingleLayer = Singleton(createDiv)
document.getElementById('btn').onclick = function () {
// 只有在调用的时候才展示
var divLayer = createSingleLayer()
}

当然,在实际应用中还是有很多适用场景的,比如登录框,还有我们可能会使用到的 Vux 之类的状态管理工具,它们实际上都是契合单例模式的

后记

单例模式是一种简单而又实用的模式,通过创建对象和管理单例的两个方法,我们就可以创造出很多实用且优雅的应用。当然,它也有自身的缺点,比如只有一个实例~

合理使用才能发挥出它的最大威力

最后,推荐一波前端学习历程,感兴趣的小伙伴可以 点击这里 ,也可以扫描下方二维码关注我的微信公众号,查看往期更多内容,欢迎 star 关注

image

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Scroll Up