设计模式 | 工作中会用到的单例模式-51CTO.COM

[[416951]]

本文转载自微信公众号「DYBOY」，作者DYBOY。转载本文请联系DYBOY公众号。

单例模式是非常常用的一种设计模式，工作中我们会用到例如弹窗、音频管理、消息管理中心、公共工具函数类等在应用中只需要单个实例的场景，这些都和单例模式密不可分。

单例模式，很常用也非常重要，将单例模式应用于程序开发设计，可减少重复代码，提升程序效率，同时单例的唯一性也使得数据流更加清晰，便于维护管理。

一、什么是单例模式

单例模式(Singleton Pattern)保证一个类只有一个实例，并提供一个访问它的全局访问点。

是不是瞬间想到了 JavaScript 中的全局变量 window、localStorage，它们在全局中提供了访问点，并且只有唯一实例。

在一些多线程编程语言中，单例模式会涉及到同步锁的问题，而 JavaScript 是单线程运行的，因此可以暂时忽略线程安全问题。

单例和单身狗类似，直到程序销毁，整个程序里都找不出第二个和它能够匹配上的

二、实现单例模式

单例模式从其定义就可以看出，是一个比较简单的设计模式，其核心思想是保证唯一实例，因此如下简单实现一个蒙层功能单例类，一步步完善。

2.1 蒙层单例类

现在的工作环境下都是基于 ES6 及以上的开发模式，因此我们直接带入 class 思想去实现，如果有需要了解相关基础内容的同学推荐阅读：《这些JS设计模式的基础知识点你都会了吗?》。

蒙层的功能：

层级最大，覆盖浏览器可视区域
阻止用户所有点击事件
透明蒙层

因此，该蒙层单例的实现如下：

/** 
 * Mask 蒙层单例 
 */ 
class Mask { 
  static instance: Mask; 
  private isShow: boolean; 
  private maskDom: HTMLDivElement; 
 
  static getInstance() { 
    if (!Mask.instance) { 
      Mask.instance = new Mask(); 
    } 
    return Mask.instance; 
  } 
 
  constructor() { 
    this.isShow = false; 
    this.maskDom = this.init(); 
  } 
 
  /** 
   * 创建蒙层DOM 
   */ 
  private init() { 
    const dom = document.createElement("div"); 
    dom.setAttribute( 
      "style", 
      "z-index: 99999; position: fixed; top: 0; left: 0; width: 100%; height: 100%; display: none; pointer-events: all; user-select: none; cursor: not-allowed;" 
    ); 
    document.body.appendChild(dom); 
    return dom; 
  } 
 
  /** 
   * show 显示蒙层 
   */ 
  public show() { 
    if (this.isShow) return; 
    this.maskDom.style["display"] = "block"; 
    this.isShow = true; 
  } 
 
  /** 
   * hide 隐藏蒙层 
   */ 
  public hide() { 
    if (!this.isShow) return; 
    this.maskDom.style["display"] = "none"; 
    this.isShow = false; 
  } 
} 
 
// 直接导出实例 
export default Mask.getInstance();

使用方式：

import Mask from "./utils/Mask"; 
 
Mask.show(); 
Mask.hide();

这种在已开始就创建实例的方式，被称作“饿汉式单例”，另一种在需要的时候才创建实例的方式被称作“懒汉式单例”。

因此“饿汉式单例”的缺点就是：类加载时就初始化，浪费内存。

不过在现代借助 Webpack 等打包构建工具，如果没有使用到这个组件，也不会将这个组件打包进来，另外在 React、Vue 框架按需加载组件的设计实现下，组件也是按需通过网络下载分包组件文件，然后缓存起来，所以浪费内存这一缺点可忽略。因此，在 JavaScript 中懒汉式和饿汉式的区分不大。

推荐使用导出的时候就导出一个实例，例如：

export default Mask.getInstance();

2.2 透明蒙层单例

在上述的导出实例中，只能调用 Mask.getInstance() ，对于其他使用者来说其实已经规避了如何判断是否是单例类的问题。

另外，如果我们的导出形式是这样的：

export default Mask;

那么其他同学在引用这个组件时候，如果不知道是一个单例类，那他就可能会直接 new Mask() 方式使用，那么就会创建多个不同的实例，失去了单例的效果，为了让单例类使用的时候能像普通类创建对象的写法一致，在使用的时候和其他普通类一样，我们把这个处理方式叫做“透明化”。

为此，稍微改动下构造函数中的判断：

constructor() { 
  if (Mask.instance) { 
    return Mask.instance; 
  } 
  this.isShow = false; 
  this.maskDom = this.init(); 
  return Mask.instance = this; 
} 
 
... 
 
export default Mask;

使用验证：

const a = new Mask(); 
a.show(); 
const b = new Mask(); 
b.hide(); 
console.log("是否相等：", a === b); 
// output: 是否相等 true，并且蒙层被隐藏

如果为了保证类的透明性，使用方式的统一，可以采用在构造函数中预先判断是否存在实例的方式来实现。

2.3 单例化工具函数

通过上述对单例模式的实现和使用，其实可以想到一个问题，单例模式，只需要保证唯一实例即可，而保证唯一实例的方式，是通过一个变量来判断当前实例是否已经被创建过，如果已经创建了，则直接返回该实例，否则创建后再返回实例。

那么通用的单例模式，应该将单例化和类的职责拆分开。

讲到这，对于前面分享的《从“图片预加载”认识代理设计模式》中的缓存代理就非常相似了，借助代理模式的思想，用闭包来缓存单例。

单例化缓存工具函数：

export const proxySingleton = (fn) => { 
  let instance; 
  return () => { 
    if (instance) return instance; 
    return instance = new fn(); 
  }; 
};

传入我们之前写的任意类，类名指向了构造函数

export const singletonMask = proxySingleton(Mask);

使用的时候：

import { singletonMask } from "./utils/ProxySingleton"; 
 
const a = singletonMask(); 
a.show(); 
const b = singletonMask(); 
b.hide(); 
console.log("是否相等：", a === b); 
// output: 是否相等 true，并且蒙层被隐藏

这样我们就将单例化和创建蒙层类职责拆分，遵循单一职责原则。

2.4 ES6 export实例 import单例

举一反三，是不是在 ES6 中直接 export 一个实例是否就可以看作是单例了呐?

export default new Mask();

import 引入是采用的单例(Singleton)模式，多次用 import 引入同一个模块时，只会引入一次该模块的实例 —— 《ECMAScript 6 入门》

因此，如果要通用的单例对象，我们可以直接在 export 的时候，就导出实例。

之前我们研究过 EventEmitter3 事件触发器的原理，为了让之在全局只有一个实例，我们的使用方法如下：

// ./utils/eventEmitter.ts 
import EventEmitter from 'eventemitter3'; 
 
export default new EventEmitter();

这样导出的 eventEmitter 就是一个单例，唯一，且全局可访问。

三、总结

单例模式在工作中经常用到，当我们有意识地使用单例管理具有唯一属性的实例，将会使得程序更容易管理维护。

结合 ES6 的 import 和 export 关键词，单例模式的应用也变得更加简便。

在实现单例中，我们有将单例和蒙层类功能拆分开，也有合在一起的，这取决于在你的项目中想要如何设计，如果单例并非是大面积的组件套用，其实还是推荐合在一起，有助于后续在单文件中维护整个功能类。