单例设计模式（2）

单例模式存在的问题

单例对 OOP 特性的支持不友好

oop的特性：封装、继承、多态、抽象；
以Id生成器代码为例，如果未来某一天，我们希望针对不同的业务采用不同的 ID 生成算法。比如，订单 ID 和用户 ID 采用不同的 ID 生成器来生成。为了应对这个需求变化，我们需要修改所有用到 IdGenerator 类的地方，这样代码的改动就会比较大。

单例会隐藏类之间的依赖关系

通过构造函数、参数传递等方式声明的类之间的依赖关系，我们通过查看函数的定义，就能很容易识别出来。
但是，单例类不需要显示创建、不需要依赖参数传递，在函数中直接调用就可以了。如果代码比较复杂，这种调用关系就会非常隐蔽。在阅读代码的时候，我们就需要仔细查看每个函数的代码实现，才能知道这个类到底依赖了哪些单例类。

单例对代码的扩展性不友好

以数据库连接池为例，数据库连接池是单例的，但是，在一个系统中存在慢sql，这些 SQL 语句在执行的时候，长时间占用数据库连接资源，导致其他 SQL 请求无法响应。我们需要将数据库连接池隔离开，一个是正常的sql执行，一个是慢sql的执行器；
如果设计为单例的模式，印象了扩展性

单例对代码的可测试性不友好

首先，单例模式的硬编码式使用方式使得在编写单元测试时无法轻松地通过 mock 替换依赖的外部资源，比如数据库。、
其次，单例类持有的成员变量相当于全局变量，被所有代码共享，
如果这些成员变量是可变的，就可能导致不同测试用例之间相互影响的问题，
需要特别注意。这种情况类似于全局变量的使用，容易造成测试结果不确定性和测试用例之间的耦合。

单例不支持有参数的构造函数

数据库连接池的情况下，需要设置数据库连接池的大小、最大的连接数、连接存活时间等

替代方案

引入外部的配置类（可以使用代码的形式、可以采用从配置文件中加载的方式），在单例类初始化时，对单例类的成员变量进行赋值

/*** 配置类，在单例类中使用依赖注入的方式或者其他方式引入*/
class Config {public static int parmaA;public static int parmaB;
}/*** 单例类*/
public class Singleton {private static Singleton instance = null;private final int paramA;private final int paramB;public Singleton() {this.paramA = Config.parmaA;this.paramB = Config.parmaA;}public static Singleton getInstance() {if (instance == null) {synchronized (Singleton.class) {if (instance == null) {instance = new Singleton();}}}return instance;}
}

替代方案

为了保证全局唯一，除了使用单例，我们还可以用静态方法来实现。这也是项目开发中经常用到的一种实现思路

// 静态方法实现方式
public class IdGenerator {private static AtomicLong id = new 	AtomicLong(0);
public static long getId() {return id.incrementAndGet();}
}
// 使用举例long id = IdGenerator.getId();

使用过程中的方法

    // 1. 老的使用方式public demofunction() {
//...long id = IdGenerator.getInstance().getId();
//...}// 2. 新的使用方式：依赖注入public demofunction(IdGenerator idGenerator) {long id = idGenerator.getId();}// 外部调用demofunction()的时候，传入idGeneratorIdGenerator idGenerator = IdGenerator.getInsance();demofunction(idGenerator);