Singleton 单例模式

1、singleton 单例模式singleton（单例模式） singleton（单例模式）属于创建型模式，提供一种对象猎取方式，保证在一定范围内是唯一的。 意图：保证一个类仅有一个实例，并提供一个拜访它的全局拜访点。 其实单例模式在前端体味的不显然，缘由有： 前端代码本身在单机运行，创建的任何变量都是自然分布式的，不需要不安影响另一个用户。 后端代码是一对多的，辨别出哪些资源是哀求间分享的，哪些是哀求内独有的很重要。 另外我们说到单例，是隐含了一个范围的，指的是在某个范围内单例，比如在一个上下文中，还是一个房间中，还是一个进程，一个线程中单例，不同场景范围会不同。 举例子 假如看不懂上面的意图

2、介绍，没有关系，设计模式需要在日常工作里用起来，结合例子可以加深你的理解，下面我预备了三个例子，让你体味什么场景下会用到这种设计模式。 多人嬉戏的分享物品 玩过嬉戏的学生都知道，我们在每局嬉戏中用法的公共物品在当前房间中是唯一的，但在嬉戏房间间却不是唯一的，所以这些公共物品绝对有不同的类去描述，那每局嬉戏中怎么拿公共物品，可以保证拿到的是当前局内唯一的？ redux 数据流 其实前端的 redux 数据流本身就是单例模式，在一个应用中，数据是唯一的，但可以有不同的 ui 用法这份唯一的数据，甚至把一个表格组件展示在两个不同地方，比如全屏模式，但数据依旧是一份，我们没有须要为了全屏展示表格，就让

3、它再发一次取数哀求，彻低可以和本来的表格分享一份数据。 数据库衔接池 每个 sql 查询都依靠数据库衔接池，假如每次查询都建立一次数据库衔接池，则建立衔接的速度会远远慢于 sql 查询速度，因此你会怎么设计数据库衔接池的猎取办法？ 意图说明 单例模式的意图很容易，几乎就是其字面含义： 意图：保证一个类仅有一个实例，并提供一个拜访它的全局拜访点。 对于多人嬉戏的分享物品，比如一口锅，要保证在一局嬉戏内唯一，就要提供一种办法拜访到唯一实例。 redux 数据流的 connect 装点器就是全局拜访点的一种设计。 数据库衔接池可以提前初始化好，并通过固定 api 提供这个唯一实例。 结构图 sing

4、leton 是单例模式的接口，客户只能通过其定义的 instance() 拜访实例，以保证单例。 代码例子 下面例子用法 typescript 编写。 class ball private _instance = undefined / 构造函数申明为 private，就可以阻挡 new ball() 行为 private constructor() public static instance = () => if (this._instance = undefined) this._instance = new ball() return this._instance / 用法 co

5、nst ball = ball.getinstance() 可以认真想想，为什么这个例子把单例写成了静态办法，而不是一个全局变量？其实全局变量也能解决问题，但因为会污染全局，要尽可能通过模块化方式解决，上面的例子就是一个较好的封装方式。 固然这只是一个最容易的例子，事实上单例模式还有几种模式： 饿汉式 初始化时就生成一份实例，这样调用时挺直就能猎取。 懒汉式 就是代码例子中写的，按需实例化，即调用的时候再实例化。 要注重，按需不一定是什么好事，假如 new 的成本很高还按需实例化，可能把系统异样的风险留到随机的触发时机，导致难以排查 bug，另外也会影响第一次实例化时的系统耗时。 对 java

6、 来说，单例还需要考虑并发性，有 双重检测、静态内部类、枚举 等方法解决，这里不详细绽开。 弊端 单例模式的问题有： 对面对对象不太友好。对封装、继承、多态支持不够友好。 不利于梳理类之间的依靠关系。究竟单例是挺直调用的，而不是在构造函数申明的，所以要梳理关系要看完每一行代码才干确定。 可拓展性不好。万一要支持多例就比较难拓展，比如全局数据流可能由于微前端计划改成多实例、数据库衔接池为了分治 sql 改成多实例，都是有可能的，在系统设计之初就要考虑到将来是否还会保持单例。 可测试性不好，由于单例是全局分享的，无法保证测试用例间的隔离。 无法用法构造函数传参。 另外单例模式还可以被工厂办法所替代，所以不用特殊