单例模式:限制类实例化次数只能一次,一个类只有一个实例,并提供一个访问它的全局访问点。
单例模式是创建型设计模式的一种。针对全局仅需一个对象的场景,如线程池、全局缓存、window 对象等。
模式特点
- 类只有一个实例
- 全局可访问该实例
- 自行实例化(主动实例化)
- 可推迟初始化,即延迟执行(与静态类/对象的区别)
JavaScript 是一门非正规面向对象的语言,并没有类的定义。而单例模式要求一个 “唯一” 和 “全局访问” 的对象,在 JavaScript 中类似全局对象,刚好满足单例模式的两个特点:“唯一” 和 “可全局访问”。虽然它不是正规的单例模式,但不可否认确实具备类单例模式的特点。
|
|
使用全局变量会有以下问题:
- 命名空间污染(变量名冲突)
- 维护时不方便管控(容易不小心覆盖)
全局变量问题折中的应对方案:
- 使用命名空间
- 闭包封装私有变量(利用函数作用域)
- ES6的 const/symbol
虽然全局变量可以实现单例,但因其自身的问题,不建议在实际项目中将其作为单例模式的应用,特别是中大型项目的应用中,全局变量的维护该是考虑的成本。
模式实现
实现方式:使用一个变量存储类实例对象(值初始为
null/undefined
)。进行类实例化时,判断类实例对象是否存在,存在则返回该实例,不存在则创建类实例后返回。多次调用类生成实例方法,返回同一个实例对象。
“简单版” 单例模式:
|
|
代码中定义了一个 Singleton
函数,函数在 JavaScript 中是“一等公民“,可以为其定义属性方法。因此我们可以在函数 Singleton
中定义一个 getInstance()
方法来管控单例,并创建返回类实例对象,而不是通过传统的 new
操作符来创建类实例对象。
this.instance
存储创建的实例对象,每次接收到创建实例对象时,判断 this.instance
是否有实例对象,有则返回,没有则创建并更新 this.instance
值,因此无论调用多少次 getInstance()
,最终都只会返回同一个 Singleton
类实例对象。
存在问题:
- 不够“透明”,无法使用
new
来进行类实例化,需约束该类实例化的调用方式:Singleton.getInstance(...)
; - 管理单例的操作,与对象创建的操作,功能代码耦合在一起,不符合 “单一职责原则”
“透明版” 单例模式:
实现 “透明版” 单例模式,意图解决:统一使用 new
操作符来获取单例对象, 而不是 Singleton.getInstance(...)
。
|
|
“透明版”单例模式解决了不够“透明”的问题,我们又可以使用 new
操作符来创建实例对象。
“代理版“ 单例模式:
通过“代理”的形式,意图解决:将管理单例操作,与对象创建操作进行拆分,实现更小的粒度划分,符合“单一职责原则”
|
|
惰性单例模式
惰性单例,意图解决:需要时才创建类实例对象。对于懒加载的性能优化,想必前端开发者并不陌生。惰性单例也是解决 “按需加载” 的问题。
需求:页面弹窗提示,多次调用,都只有一个弹窗对象,只是展示信息内容不同。
开发这样一个全局弹窗对象,我们可以应用单例模式。为了提升它的性能,我们可以让它在我们需要调用时再去生成实例,创建 DOM 节点。
|
|
代码中演示是一个通用的 “惰性单例” 的创建方式,如果还需要 createLoginLayer
登录框, createFrame
Frame框, 都可以调用 getSingleton(...)
生成对应实例对象的方法。
适用场景
“单例模式的特点,意图解决:维护一个全局实例对象。”
- 引用第三方库(多次引用只会使用一个库引用,如 jQuery)
- 弹窗(登录框,信息提升框)
- 购物车 (一个用户只有一个购物车)
- 全局态管理 store (Vuex / Redux)
项目中引入第三方库时,重复多次加载库文件时,全局只会实例化一个库对象,如 jQuery
,lodash
,moment
…, 其实它们的实现理念也是单例模式应用的一种:
|
|
优缺点
- 优点:适用于单一对象,只生成一个对象实例,避免频繁创建和销毁实例,减少内存占用。
- 缺点:不适用动态扩展对象,或需创建多个相似对象的场景。
TIPS: 多线程编程语言中,单例模式会涉及同步锁的问题。而 JavaScript 是单线程的编程语言,暂可忽略该问题。
参考文章
本文首发Github,期待Star!
https://github.com/ZengLingYong/blog
作者:以乐之名
本文原创,有不当的地方欢迎指出。转载请指明出处。