3.单例模式（Singleton Pattern）

定义

确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。

代码

饿汉式

public class EagerSingleton {
    private static final EagerSingleton instance = new EagerSingleton();
    private EagerSingleton() {
    }
    public static EagerSingleton getInstance() {
        return instance;
    }
    public static void main(String[] args) {
        EagerSingleton instance1 = EagerSingleton.getInstance();
        EagerSingleton instance2 = EagerSingleton.getInstance();
        System.out.println(instance1 == instance2);
    }
}

懒汉式

双重检测锁

/**
 * 双重检查锁定（Double-Check Locking）
 * volatile
 */
public class LazySingleton {
    private volatile static LazySingleton instance = null;
    private LazySingleton() {
    }
    public static LazySingleton getInstance() {
        if (instance == null) {
            synchronized (LazySingleton.class) {
                if (instance == null) {
                    instance = new LazySingleton();
                }
            }
        }
        return instance;
    }
    public static void main(String[] args) {
        LazySingleton instance1 = LazySingleton.getInstance();
        LazySingleton instance2 = LazySingleton.getInstance();
        System.out.println(instance1 == instance2);
    }
}

IoDH

/**
 * 一次调用getInstance（）时将加载内部类HolderClass，在该内部类中定义了一个static类型的变量instance，
 * 此时会首先初始化这个成员变量，由Java虚拟机来保证其线程安全性，确保该成员变量只能初始化一次。由于getInstance（）方法没有被任何线程锁定，因此其性能不会造成任何影响。
 * <p>
 * 通过使用IoDH，既可以实现延迟加载，又可以保证线程安全，不影响系统性能。因此，IoDH不失为一种最好的Java语言单例模式实现方式；其缺点是与编程语言本身的特性相关，很多面向对象语言不支持IoDH
 */
public class InitializationOnDemandHolder {
    private InitializationOnDemandHolder() {
    }
    private static class HolderClass {
        private final static InitializationOnDemandHolder initializationOnDemandHolder = new InitializationOnDemandHolder();
    }
    public static InitializationOnDemandHolder getInstance() {
        return HolderClass.initializationOnDemandHolder;
    }
    public static void main(String[] args) {
        InitializationOnDemandHolder instance1 = getInstance();
        InitializationOnDemandHolder instance2 = getInstance();
        System.out.println(instance1 == instance2);
    }
}

枚举

public class SomeClassNeedSingleton {
    private SomeClassNeedSingleton(){}
    public enum ConfirmEnum {
        INSTANCE;
        private SomeClassNeedSingleton singleton = null;
        ConfirmEnum() {
            singleton=new SomeClassNeedSingleton();
        }
        public SomeClassNeedSingleton getInstance(){
            return singleton;
        }
    }
}
SomeClassNeedSingleton instance1 = SomeClassNeedSingleton.ConfirmEnum.INSTANCE.getInstance();
SomeClassNeedSingleton instance2 = SomeClassNeedSingleton.ConfirmEnum.INSTANCE.getInstance();
System.out.println(instance1==instance2);

对比

克隆、反射和反序列化对单例模式的破坏
除了直接通过new和使用工厂来创建对象以外，还可以通过克隆、反射和反序列化等方式来创建对象。
但是用这些方式来创建对象时有可能会导致单例对象的不唯一，如何解决这些问题呢？

1. 为了防止客户端使用克隆方法来创建对象，单例类不能实现Cloneable接口，即不能支持clone()方法。
2. 由于反射可以获取到类的构造函数，包括私有构造函数，因此反射可以生成新的对象。【如何解决：采用枚举实现】
   1. 采用一些传统的实现方法都不能避免客户端通过反射来创建新对象，此时，我们可以通过枚举单例对象的方式来解决该问题。
3. 在原型模式中，我们可以通过反序列化实现深克隆，反序列化也会生成新的对象。具体来说就是每调用一次readObject()方法，都将会返回一个新建的实例对象，这个新建的实例对象不同于类在初始化时创建的实例对象。
   1. 那么，如何防止反序列化创建对象呢？解决方法一是类不能实现Serializable接口，即不允许该类支持序列化，这将导致类的应用受限制（有时候我们还是需要对一个对象进行持久化处理）；解决方法二就是本文将要详细介绍的枚举实现。

      优点：

      （1）单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严格控制客户怎样以及何时访问它。
      （2）由于在系统内存中只存在一个对象，因此可以节约系统资源。对于一些需要频繁创建和销毁的对象，单例模式无疑可以提高系统的性能。
      （3）允许可变数目的实例。基于单例模式，开发人员可以进行扩展，使用与控制单例对象相似的方法来获得指定个数的实例对象，既节省系统资源，又解决了由于单例对象共享过多有损性能的问题。（注：自行提供指定数目实例对象的类可称之为多例类。）

      缺点：

      （1）由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。
      （2）单例类的职责过重，在一定程度上违背了单一职责原则。因为单例类既提供了业务方法，又提供了创建对象的方法（工厂方法），将对象的创建和对象本身的功能耦合在一起。
      （3）现在很多面向对象语言（如Java、C＃）的运行环境都提供了自动垃圾回收技术，因此，如果实例化的共享对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次利用时又将重新实例化，这将导致共享的单例对象状态的丢失。

3．适用场景在以下情况下可以考虑使用单例模式：
（1）系统只需要一个实例对象。例如，系统要求提供一个唯一的序列号生成器或资源管理器，或者需要考虑资源消耗太大而只允许创建一个对象。
（2）客户调用类的单个实例只允许使用一个公共访问点。除了该公共访问点，不能通过其他途径访问该实例。

UML分析

4.简单工厂模式（Simple Factory Pattern）

定义

定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态（static）方法，因此简单工厂模式又被称为静态工厂方法（Static Factory Method）模式，它属于类创建型模式。

优点

所有的工厂模式都强调一点：两个类A和B之间的关系应该仅仅是A创建B或是A使用B，而不能两种关系都有。将对象的创建和使用分离，也使得系统更加符合单一职责原则，有利于对功能的复用和系统的维护。
防止用来实例化一个类的数据和代码在多个类中到处都是，可以将有关创建的知识搬移到一个工厂类中
从一组工厂方法中选择一个意义明确的工厂方法，比从一组名称相同参数不同的构造函数中选择一个构造函数要方便很多

缺点

（1）由于工厂类集中了所有产品的创建逻辑，职责过重，一旦不能正常工作，整个系统都要受到影响。
（2）使用简单工厂模式势必会增加系统中类的个数（引入了新的工厂类），增加了系统的复杂度和理解难度。
（3）系统扩展困难。一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。
（4）简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

UML分析

代码

比较简单 就不放了

5.工厂方法模式（Factory Method Pattern）

引入

简单工厂模式虽然简单，但存在一个很严重的问题：当系统中需要引入新产品时，由于静态工厂方法通过所传入参数的不同来创建不同的产品，这必定要修改工厂类的源代码，将违背开闭原则

工厂方法模式是简单工厂模式的延伸，它继承了简单工厂模式的优点，同时还弥补了简单工厂模式的不足。工厂方法模式是使用频率最高的设计模式之一，是很多开源框架和API类库的核心模式。

主要优点

（1）在工厂方法模式中，工厂方法用来创建客户所需要的产品，同时还向客户隐藏了哪种具体产品类将被实例化这一细节。用户只需要关心所需产品对应的工厂，无须关心创建细节，甚至无须知道具体产品类的类名。
（2）基于工厂角色和产品角色的多态性设计是工厂方法模式的关键。它能够让工厂可以自主确定创建何种产品对象，而如何创建这个对象的细节则完全封装在具体工厂内部。工厂方法模式之所以又被称为多态工厂模式，正是因为所有的具体工厂类都具有同一抽象父类。
（3）使用工厂方法模式的另一个优点是在系统中加入新产品时，无须修改抽象工厂和抽象产品提供的接口，无须修改客户端，也无须修改其他的具体工厂和具体产品，而只要添加一个具体工厂和具体产品就可以了。这样，系统的可扩展性也就变得非常好，完全符合开闭原则。

主要缺点

（1）在添加新产品时，需要编写新的具体产品类，而且还要提供与之对应的具体工厂类，系统中类的个数将成对增加，在一定程度上增加了系统的复杂度，有更多的类需要编译和运行，会给系统带来一些额外的开销。
（2）由于考虑到系统的可扩展性，需要引入抽象层，在客户端代码中均使用抽象层进行定义，增加了系统的抽象性和理解难度，且在实现时可能需要用到DOM、反射等技术，增加了系统的实现难度。
3．适用场景在以下情况下可以考虑使用工厂方法模式：
（1）客户端不知道其所需要的对象的类。在工厂方法模式中，客户端不需要知道具体产品类的类名，只需要知道所对应的工厂即可，具体的产品对象由具体工厂类创建，可将具体工厂类的类名存储在配置文件或数据库中。
（2）抽象工厂类通过其子类来指定创建哪个对象。在工厂方法模式中，抽象工厂类只需要提供一个创建产品的接口，而由其子类来确定具体要创建的对象，利用面向对象的多态性和里氏代换原则，在程序运行时，子类对象将覆盖父类对象，从而使得系统更容易扩展。

6.抽象工厂模式（Abstract Factory Pattern）

抽象工厂模式为创建一组对象提供了一种解决方案。与工厂方法模式相比，抽象工厂模式中的具体工厂不只是创建一种产品，它负责创建一族产品。抽象工厂模式定义如下
提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式。

抽象工厂模式最大的缺点。在抽象工厂模式中，增加新的产品族很方便，但是增加新的产品等级结构很麻烦，抽象工厂模式的这种性质称为开闭原则的倾斜性。开闭原则要求系统对扩展开放，对修改封闭，通过扩展达到增强其功能的目的，对于涉及多个产品族与多个产品等级结构的系统，其功能增强包括两方面：
（1）增加产品族。对于增加新的产品族，抽象工厂模式很好地支持了开闭原则，只需要增加具体产品并对应增加一个新的具体工厂，对已有代码无须做任何修改。
（2）增加新的产品等级结构。对于增加新的产品等级结构，需要修改所有的工厂角色，包括抽象工厂类，在所有的工厂类中都需要增加生产新产品的方法，违背了开闭原则。正因为抽象工厂模式存在开闭原则的倾斜性，它以一种倾斜的方式来满足开闭原则，为增加新产品族提供方便，但不能为增加新产品结构提供这样的方便。因此，要求设计人员在设计之初就能够全面考虑，不会在设计完成之后向系统中增加新的产品等级结构，也不会删除已有的产品等级结构，否则将导致系统出现较大的修改，为后续维护工作带来诸多麻烦。
1．主要优点抽象工厂模式的主要优点如下：
（1）抽象工厂模式隔离了具体类的生成，使得客户并不需要知道什么被创建。由于这种隔离，更换一个具体工厂就变得相对容易，所有的具体工厂都实现了在抽象工厂中声明的那些公共接口，因此只需改变具体工厂的实例，就可以在某种程度上改变整个软件系统的行为。
（2）当一个产品族中的多个对象被设计成一起工作时，它能够保证客户端始终只使用同一个产品族中的对象。
（3）增加新的产品族很方便，无须修改已有系统，符合开闭原则。
2．主要缺点抽象工厂模式的主要缺点是：增加新的产品等级结构麻烦，需要对原有系统进行较大的修改，甚至需要修改抽象层代码，这显然会带来较大的不便，违背了开闭原则。
3．适用场景在以下情况下可以考虑使用抽象工厂模式：
（1）一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有类型的工厂模式都是很重要的，用户无须关心对象的创建过程，将对象的创建和使用解耦。
（2）系统中有多于一个的产品族，而每次只使用其中某一个产品族。可以通过配置文件等方式来使得用户可以动态改变产品族，也可以很方便地增加新的产品族。
（3）属于同一个产品族的产品将在一起使用，这一约束必须在系统的设计中体现出来。同一个产品族中的产品可以是没有任何关系的对象，但是它们都具有一些共同的约束。例如同一操作系统下的按钮和文本框，按钮与文本框之间没有直接关系，但它们都是属于某一操作系统的，此时具有一个共同的约束条件：操作系统的类型。
（4）产品等级结构稳定，设计完成之后，不会向系统中增加新的产品等级结构或者删除已有的产品等级结构。

7.原型模式

默认是浅拷贝,如果需要深拷贝,则需要实现序列化接口,并且利用IO进行 序列化和反序列化,得到新对象
Java语言提供的Cloneable接口和Serializable接口的代码非常简单，它们都是空接口，这种空接口也称为标识接口。标识接口中没有任何方法的定义，其作用是告诉JRE这些接口的实现类是否具有某个功能，例如是否支持克隆、是否支持序列化等。

变种:管理器

1．主要优点原型模式的主要优点如下：
（1）当创建新的对象实例较为复杂时，使用原型模式可以简化对象的创建过程，通过复制一个已有实例可以提高新实例的创建效率。
（2）扩展性较好。由于在原型模式中提供了抽象原型类，在客户端可以针对抽象原型类进行编程，而将具体原型类写在配置文件中，增加或减少具体原型类对原有系统都没有任何影响。
（3）原型模式提供了简化的创建结构。工厂方法模式常常需要有一个与产品类等级结构相同的工厂等级结构，而原型模式就不需要这样。原型模式中产品的复制是通过封装在原型类中的克隆方法实现的，无须专门的工厂类来创建产品。
（4）可以使用深克隆的方式保存对象的状态。使用原型模式将对象复制一份并将其状态保存起来，以便在需要的时候使用，例如恢复到某一历史状态，可辅助实现撤销操作。
2．主要缺点原型模式的主要缺点如下：
（1）需要为每一个类配备一个克隆方法，而且该克隆方法位于一个类的内部。当对已有的类进行改造时，需要修改源代码，违背了开闭原则。
（2）在实现深克隆时需要编写较为复杂的代码，而且当对象之间存在多重的嵌套引用时，为了实现深克隆，每一层对象对应的类都必须支持深克隆，实现起来可能会比较麻烦。
3．适用场景在以下情况下可以考虑使用原型模式：
（1）创建新对象成本较大（例如初始化需要占用较长的时间，占用太多的CPU资源或网络资源）。新的对象可以通过原型模式对已有对象进行复制来获得，如果是相似对象，则可以对其成员变量稍作修改。
（2）如果系统要保存对象的状态，而对象的状态变化很小，或者对象本身占用内存较少时，可以使用原型模式配合备忘录模式（本书第21章介绍）来实现。
（3）需要避免使用分层次的工厂类来创建分层次的对象，并且类的实例对象只有一个或很少的几个组合状态。通过复制原型对象得到新实例可能比使用构造函数创建一个新实例更加方便。

8.建造者模式

建造者模式（Builder Pattern）：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。

建造者模式的核心在于如何一步一步地构建一个包含多个组成部件的完整对象，使用相同的构建过程构建不同的产品。在软件开发中，如果需要创建复杂对象，并希望系统具备很好的灵活性和可扩展性，可以考虑使用建造者模式。
1．主要优点建造者模式的主要优点如下：
（1）在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
（2）每个具体建造者都相对独立，而与其他具体建造者无关。因此，可以很方便地替换具体建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。由于指挥者类针对抽象建造者编程，增加新的具体建造者无须修改原有类库的代码，系统扩展方便，符合开闭原则。
（3）可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
2．主要缺点建造者模式的主要缺点如下：
（1）建造者模式所创建的产品一般具有较多的共同点，其组成部分相似。如果产品之间的差异性很大，例如很多组成部分都不相同，就不适合使用建造者模式，因此其使用范围受到一定的限制。
（2）如果产品的内部结构复杂且多变，可能会需要定义很多具体建造者类来实现这种变化，这就导致系统变得很庞大，增加系统的理解难度和运行成本。
3．适用场景在以下情况下可以考虑使用建造者模式：
（1）需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员变量。
（2）需要生成的产品对象的属性相互依赖，需要指定其生成顺序。
（3）对象的创建过程独立于创建该对象的类。在建造者模式中通过引入指挥者类，将创建过程封装在指挥者类中，而不在建造者类和客户类中。
（4）隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。