单例模式

设计原则

1. 单一职责原则
要求一个接口或者类只有一个原因引起变化，也就是一个接口和类只有一个职责。

2. 里氏替换原则
只要父类能出现的地方子类都可以出现，而且替换为子类也不会产生任何错误或者异常。

3. 依赖倒置原则 Dependence Inversion Princple
实现类间不发生直接的依赖关系，其依赖关系通过接口或抽象类产生。
接口或抽象类不依赖于实现类。
实现类依赖接口或者抽象类。
即——“面向接口编程”

4. 接口隔离原则
接口尽量细化，接口中的方法尽量少（但是不能违反单一职责原则）。

5. 迪米特法则（最少知识原则）
一个类应该对自己需要耦合或调用的类知道的最少，即让类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，多使用访问权限。
出现在成员变量、方法的输入输出参数中的类称为朋友类，而出现在方法内部的不属于朋友类。
一个类要保证只和自己的朋友类产生交流。

6. 开闭原则
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

设计模式

单例模式

定义

定义：Ensure a class has only one instance, and provide a global point of access to it.
确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。

要求一个类只能生成一个对象，所有对象对它的依赖都是相同的。

public class Singleton {
    private static final Singleton singleton = new Singleton();

    //私有化构造方法
    private Singleton(){}
    
    //提供公共访问方法
    public static Singleton getSingleton(){
        return  singleton;
    }
    
    //类中其他方法，尽量是静态的
    public static  void doSomething(){
    }
}

pros & cons

优点：

1. 减少内存开支，性能开销
2. 避免对资源的多重占用
3. 可以在系统设置全局的访问点，优化和共享资源访问

——————————————————————————————————————————

缺点：

1. 拓展难，单例模式一般没有接口，只能通过修改代码的方式来拓展。
2. 对测试不利，没有完成单例模式时，无法进行测试。
3. 与单一职责冲突，将“获得单例”和业务逻辑混在了一起。

使用场景

要求一个类仅有一个对象，如果有多个对象就会产生“不良反应”。

如：

1. 整个项目需要一个共享访问点或共享数据。
2. 要求生成唯一序列号的环境。
3. 创建一个对象需要消耗的资源过多。
4. 需要定义大量静态常量和静态方法的环境（如工具类）。

注意事项

在高并发情况下，可能出现线程同步问题。
为了防止内存中出现多个实例，可以在getInstance方法前增加synchronized关键字，也可以在getInstance方法内增加同步代码块，但这都不是优秀的单例模式。
建议使用上面代码块展示的写法，称为饿汉式单例。

单例模式的拓展

如果只需要一个对象，使用单例模式即可。如果需要产生两三个对象呢？ 多例模式。