23种设计模式

什么是设计模式

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。 毫无疑问，设计模式于己于他人于系统都是多赢的，设计模式使代码编制真正工程化，设计模式是软件工程的基石，如同大厦的一块块砖石一样。项目中合理的运用设计模式可以完美的解决很多问题，每种模式在现在中都有相应的原理来与之对应，每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的核心解决方案，这也是它能被广泛应用的原因。简单说：

模式：在某些场景下，针对某类问题的某种通用的解决方案。

场景：项目所在的环境

问题：约束条件，项目目标等

解决方案：通用、可复用的设计，解决约束达到目标。

设计模式的三个分类

创建型模式：对象实例化的模式，创建型模式用于解耦对象的实例化过程。

结构型模式：把类或对象结合在一起形成一个更大的结构。

行为型模式：类和对象如何交互，及划分责任和算法。

1. 创建型模式

创建型模式的主要关注点是：怎样创建对象？，它的主要特点是：将对象的创建与使用分离。

这样可以降低系统的耦合度，使用者不需要关注对象的创建细节。

创建型模式分为：单例模式、工厂方法模式、抽象工程模式、原型模式、建造者模式

1.1 单例模式

单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。

这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。

单例模式，它的定义就是确保某一个类只有一个实例，并且提供一个全局访问点。

单例模式具备典型的3个特点：1、只有一个实例。 2、自我实例化。 3、提供全局访问点。

因此当系统中只需要一个实例对象或者系统中只允许一个公共访问点，除了这个公共访问点外，不能通过其他访问点访问该实例时，可以使用单例模式。

单例模式的主要优点就是节约系统资源、提高了系统效率，同时也能够严格控制客户对它的访问。也许就是因为系统中只有一个实例，这样就导致了单例类的职责过重，违背了“单一职责原则”，同时也没有抽象类，所以扩展起来有一定的困难。其UML结构图非常简单，就只有一个类

1.1.1 单例模式的结构

单例模式的主要有以下角色：

• 单例类：只能创建一个实例的类
• 访问类：使用单例类

1.1.2 单例模式的实现

单例设计模式分类两种：

• 饿汉式：类加载就会导致该单实例对象被创建

• 懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建

饿汉式 1：静态变量

该方式在成员位置声明 Singleton 类型的静态变量，并创建 Singleton 类的对象 instance。

/**
 * 饿汉式：静态成员变量
 */
public class Singleton {
    // 1.私有构造方法
    private Singleton() {}
    // 2.在本类中创建本类对象
    private static Singleton instance = new Singleton();
    // 3.提供一个公共的访问方式，让外界获取该对象
    public static Singleton getInstance() {
        return instance;
    }
}

instance 对象是随着类的加载而创建的，如果该对象很大，却一直没有使用就会造成内存的浪费。

​ 测试每次获取到的 Singleton 对象都是同一个：

public class Client {
 public static void main(String[] args) {
     // 创建Singleton类的对象
     Singleton instance1 = Singleton.getInstance();
     Singleton instance2 = Singleton.getInstance();
     // 判断获取到的两个是否是同一个对象
     System.out.println(instance1 == instance2); // true
 }
}

饿汉式 2：静态代码块

该方式在成员位置声明 Singleton 类型的静态变量，而对象的创建是在静态代码块中，也是随着类的加载而创建。

/**
 * 饿汉式: 静态代码块
 */
public class Singleton {
    // 声明Singleton类型的变量
    private static Singleton instance; // null
    //在静态代码块中进行赋值
    static {
        instance = new Singleton();
    }
    // 私有构造方法
    private Singleton() {}
    //对外提供获取该类对象的方法
    public static Singleton getInstance() {
        return instance;
    }
}

该方式和饿汉式的方式 1 基本一样，所以该方式也存在内存浪费问题。

懒汉式 1：线程不安全

该方式在成员位置声明 Singleton 类型的静态变量，并没有进行对象的赋值操作，那么什么时候赋值的呢？

当调用 getInstance() 方法获取 Singleton 类的对象的时候才创建 Singleton 类的对象，这样就实现了懒加载效果。

/**
 * 懒汉式: 线程不安全
 */
public class Singleton {
    // 声明Singleton类型的变量instance, 没有赋值
    private static Singleton instance;
    // 私有构造方法
    private Singleton() {}
    // 对外提供访问方式
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

但是，如果是多线程环境，会出现线程安全问题。

懒汉式 2：线程安全

在懒汉式 1 的基础上，使用 synchronized 关键字解决了线程安全问题，但是该方法的执行效率特别低。

注意：其实只有在初始化 instance 的时候才会出现线程安全问题，一旦初始化完成就不存在了。

/**
 * 懒汉式: 线程不安全
 */
public class Singleton {
    // 声明Singleton类型的变量instance, 没有赋值
    private synchronized static Singleton instance;
    // 私有构造方法
    private Singleton() {}
    // 对外提供访问方式
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

懒汉式 3：双重检查锁🚀

再来讨论一下懒汉模式中加锁的问题，对于 getInstance() 方法来说，绝大部分的操作都是读操作，读操作是线程安全的，所以没有必要让每个线程必须持有锁才能调用该方法，可以调整加锁的时机。

由此产生了一种新的实现方式：双重检查锁模式（double check）

/**
 * 双重检查锁方式(有风险)
 */
public class Singleton {
    // 私有构造方法
    private Singleton() {}
    // 声明Singleton类型的变量
    private static Singleton instance;
    // 对外提供公共的访问方式
    public static Singleton getInstance() {
        // 第一次判断,如果instance不为null,不需要抢占锁,直接返回对象
        if (instance == null) {
            synchronized (Singleton.class) {
                // 第二次判断,抢占到锁以后再次判断
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return  instance;
    }
}

双重检查锁模式是一种比较的单例实现模式，解决了单例、性能、线程安全问题，但是虽然看上去完美无缺，其实是存在问题的；

在多线程的情况下，可能会出现空指针问题，原因是 JVM 在实例化对象的时候会进行优化和指令重排序操作。

要解决双重检查锁带来空指针的问题，只需要使用 volatile 关键字, volatile 关键字可以保证可见性和有序性。

/**
 * 双重检查锁方式(标准)
 */
public class Singleton {
    // 私有构造方法
    private Singleton() {}
    // 声明Singleton类型的变量,使用volatile保证可见性和有序性
    private static volatile Singleton instance;
    // 对外提供公共的访问方式
    public static Singleton getInstance() {
        // 第一次判断,如果instance不为null,不需要抢占锁,直接返回对象
        if (instance == null) {
            synchronized (Singleton.class) {
                // 第二次判断,抢占到锁以后再次判断
                if (instance == null) {
                    instance = new Singleton();
                }
            }
        }
        return  instance;
    }
}

添加 volatile 关键字之后的双重检查锁模式是一种比较好的单例实现模式，能够保证在多线程的情况下线程安全也不会有性能问题。

懒汉式 4：静态内部类🚀

静态内部类单例模式中实例由内部类创建，由于 JVM 在加载外部类的过程中，是不会加载静态内部类的，只有内部类的属性/方法被调用时才会被加载，并初始化其静态属性。静态属性由于被 static 修饰，保证只被实例化一次，并且严格保证实例化顺序。

/**
 * 静态内部类方式
 */
public class Singleton {
    // 私有构造方法
    private Singleton() {}
    // 定义一个静态内部类
    private static class SingletonHolder {
        // 在内部类中声明并初始化外部类的对象
        private static final Singleton INSTANCE = new Singleton();
    }
    // 提供公共的访问方式
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

第一次加载 Singleton 类时不会去初始化 INSTANCE，只有第一次调用 getInstance()，虚拟机加载 SingletonHolder 并初始化 INSTANCE，这样不仅能确保线程安全，也能保证 Singleton 类的唯一性。

静态内部类单例模式是一种优秀的单例模式，是开源项目中比较常用的一种单例模式。在没有加任何锁的情况下，保证了多线程下的安全，并且没有任何性能影响和空间的浪费。

饿汉式 3：枚举🚀
首先，枚举方式是饿汉式单例模式，如果不考虑浪费内存空间的问题，这是极力推荐的单例实现模式。

因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特性来实现单例模式。

枚举的写法非常简单，而且枚举方式是所用单例实现中唯一一种不会被破坏的单例实现模式。

/**
 * 饿汉式：枚举实现
 */
public enum Singleton {
    INSTANCE
}

1.1.3 存在的问题

有两种方式可以使上面定义的单例类可以创建多个对象（枚举方式除外），分别是序列化和反射。

枚举方式是利用了 Java 特性实现的单例模式，不会被破坏，其他实现方式都有可能会被破坏

序列化破坏单例

​ 问题演示：下面代码运行结果是false，表明序列化和反序列化破坏了单例设计模式。

/**
 * 测试使用序列化破坏单例模式
 */
public class Client {
    public static void main(String[] args) throws Exception {
        Singleton s1 = readObjectFromFile();
        Singleton s2 = readObjectFromFile();
        System.out.println(s1 == s2); // false
    }
    // 从文件读取数据（对象）
    public static Singleton readObjectFromFile() throws Exception {
        // 1.创建对象输入流对象
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("C:\\Users\\Think\\Desktop\\a.txt"));
        // 2.读取对象
        Singleton instance = (Singleton) ois.readObject();
        // 3.释放资源
        ois.close();
        return instance;
    }
    // 向文件中写数据（对象）
    public static void writeObject2File() throws Exception {
        // 1.获取Singleton对象
        Singleton instance = Singleton.getInstance();
        // 2.创建对象输出流对象
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("C:\\Users\\Think\\Desktop\\a.txt"));
        // 3.写对象
        oos.writeObject(instance);
        // 4.释放资源
        oos.close();
    }
}

解决方案：在 Singleton 类中添加readResolve()方法。

在反序列化时被反射调用，如果定义了这个方法，就返回这个方法的值，如果没有定义，则返回新 new 出来的对象。

/**
 * 静态内部类方式(解决序列化破解单例模式)
 */
public class Singleton implements Serializable {
    // 私有构造方法
    private Singleton() {}
    // 提供公共的访问方式
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
    /**
     * 下面是为了解决序列化反序列化破解单例模式
     * 当进行反序列化时，会自动调用该方法，将该方法的返回值直接返回
     */
    private Object readResolve() {
        return SingletonHolder.INSTANCE;
    }
    // 定义一个静态内部类
    private static class SingletonHolder {
        // 在内部类中声明并初始化外部类的对象
        private static final Singleton INSTANCE = new Singleton();
    }
}

简单的源码解析：ObjectInputStream 类

public final Object readObject() throws IOException, ClassNotFoundException{
    ...
    // if nested read, passHandle contains handle of enclosing object
    int outerHandle = passHandle;
    try {
        Object obj = readObject0(false); // 重点查看readObject0方法
    .....
}
    
private Object readObject0(boolean unshared) throws IOException {
	...
    try {
		switch (tc) {
			...
			case TC_OBJECT:
				return checkResolve(readOrdinaryObject(unshared)); // 重点查看readOrdinaryObject方法
			...
        }
    } finally {
        depth--;
        bin.setBlockDataMode(oldMode);
    }    
}
    
private Object readOrdinaryObject(boolean unshared) throws IOException {
	...
	//isInstantiable 返回true，执行 desc.newInstance()，通过反射创建新的单例类，
    obj = desc.isInstantiable() ? desc.newInstance() : null; 
    ...
    // 在Singleton类中添加 readResolve 方法后 desc.hasReadResolveMethod() 方法执行结果为true
    if (obj != null && handles.lookupException(passHandle) == null && desc.hasReadResolveMethod()) {
    	// 通过反射调用 Singleton 类中的 readResolve 方法，将返回值赋值给rep变量
    	// 这样多次调用ObjectInputStream类中的readObject方法，继而就会调用我们定义的readResolve方法，所以返回的是同一个对象。
    	Object rep = desc.invokeReadResolve(obj);
     	...
    }
    return obj;
}

反射破坏单例

问题演示：下面代码运行结果是false，说明反射破坏了单例设计模式。

/**
 * 测试使用反射破坏单例模式
 */
public class Client {
    public static void main(String[] args) throws Exception {
        // 1.获取Singleton的字节码对象
        Class clazz = Singleton.class;
        // 2.获取无参构造方法对象
        Constructor cons = clazz.getDeclaredConstructor();
        // 3.取消访问检查
        cons.setAccessible(true);
        // 4.创建Singleton对象
        Singleton s1 = (Singleton) cons.newInstance();
        Singleton s2 = (Singleton) cons.newInstance();
        System.out.println(s1 == s2); // false
    }
}

再次强调，枚举方式不会出现这两个问题。

解决方案：当通过反射方式调用构造方法进行创建时，直接抛异常

/**
 * 静态内部类方式(解决反射破坏单例模式)
 */
public class Singleton {
    private static boolean flag = false;
    // 私有构造方法
    private Singleton() {
        synchronized (Singleton.class) {
            // 如果是true,说明非第一次访问,直接抛一个异常,如果是false,说明第一次访问
            if (flag) {
                throw new RuntimeException("不能创建多个对象");
            }
            flag = true;
        }
    }
    // 提供公共的访问方式
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
    // 定义一个静态内部类
    private static class SingletonHolder {
        // 在内部类中声明并初始化外部类的对象
        private static final Singleton INSTANCE = new Singleton();
    }
}

1.1.4 JDK 源码 - Runtime 类

Runtime 类使用的就是单例设计模式。

源码查看：下面是 Runtime 类的源码，是静态变量方式的饿汉单例模式。

public class Runtime {
    private static Runtime currentRuntime = new Runtime();

    /**
     * Returns the runtime object associated with the current Java application.
     * Most of the methods of class <code>Runtime</code> are instance
     * methods and must be invoked with respect to the current runtime object.
     *
     * @return  the <code>Runtime</code> object associated with the current
     *          Java application.
     */
    public static Runtime getRuntime() {
        return currentRuntime;
    }

    /** Don't let anyone else instantiate this class */
    private Runtime() {}
    ...
}

使用 Runtime 类中的方法：

/**
 *  RuntimeDemo
 */
public class RuntimeDemo {
    public static void main(String[] args) throws IOException {
        // 获取Runtime类的对象
        Runtime runtime = Runtime.getRuntime();
        // 调用runtime的方法exec,参数要的是一个命令
        Process process = runtime.exec("ifconfig");
        // 调用process对象的获取输入流的方法
        InputStream is =  process.getInputStream();
        byte[] arr = new byte[1024 * 1024 * 100];
        // 读取数据
        int len = is.read(arr); // 返回读到的字节的个数
        // 将字节数组转换为字符串输出到控制台
        System.out.println(new String(arr, 0, len, "GBK"));
    }
}      

1.2 工厂方法模式

应用场景：

​ 1、当你不知道该使用对象的确切类型的时候

​ 2、当你希望为库或者框架提供扩展其内部组件的方法时

主要优点：

​ 将具体产品和创建者解耦 、符合单一职责原则、符合开闭原则

作为抽象工厂模式的孪生兄弟，工厂方法模式定义了一个创建对象的接口，但由子类决定要实例化的类是哪一个，也就是说工厂方法模式让实例化推迟到子类。

1.2.1 概述

需求：设计一个咖啡店点餐系统。

设计一个咖啡类（Coffee），并定义其两个子类：美式咖啡【AmericanCoffee】和拿铁咖啡【LatteCoffee】

再设计一个咖啡店类（CoffeeStore），咖啡店具有点咖啡的功能。

具体类的设计如下：

在 Java 中，万物皆对象，这些对象都需要创建，如果创建的时候直接 new 该对象，就会对该对象耦合严重。假如我们要更换对象，所有 new 对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则。

如果我们使用工厂来生产对象，我们就只和工厂打交道就可以了，彻底和对象解耦，如果要更换对象，直接在工厂里更换该对象即可，达到了与对象解耦的目的。所以说，工厂模式最大的优点就是：解耦。

3 种工厂的使用：

• 简单工厂模式（不属于 GOF 的 23 种经典设计模式）

• 工厂方法模式

• 抽象工厂模式

1.2.2 简单工厂模式

简单工厂不是一种设计模式，反而比较像是一种编程习惯。

1.2.2.1 结构

简单工厂包含如下角色：

• 抽象产品：定义了产品的规范，描述了产品的主要特性和功能。
• 具体产品：实现或者继承抽象产品的子类。
• 具体工厂：提供了创建产品的方法，调用者通过该方法来获取产品。

下例中，抽象产品是咖啡抽象类，具体产品是美式咖啡和拿铁咖啡；

1.2.2.2 实现

使用简单工厂对上面案例进行改进，类图如下：

工厂类代码如下：

public class SimpleCoffeeFactory {

    public Coffee createCoffee(String type) {
        Coffee coffee = null;
        if("americano".equals(type)) {
            coffee = new AmericanoCoffee();
        } else if("latte".equals(type)) {
            coffee = new LatteCoffee();
        }
        return coffee;
    }
}

工厂（factory）处理创建对象的细节，一旦有了SimpleCoffeeFactory，CoffeeStore类中的orderCoffee()就变成此对象的客户，后期如果需要Coffee对象直接从工厂中获取即可。这样也就解除了和Coffee实现类的耦合，同时又产生了新的耦合，CoffeeStore对象和SimpleCoffeeFactory工厂对象的耦合，工厂对象和商品对象的耦合。

后期如果再加新品种的咖啡，我们势必要需求修改SimpleCoffeeFactory的代码，违反了开闭原则。工厂类的客户端可能有很多，比如创建美团外卖等，这样只需要修改工厂类的代码，省去其他的修改操作。

1.2.2.43优缺点

优点：

封装了创建对象的过程，可以通过参数直接获取对象。把对象的创建和业务逻辑层分开，这样以后就避免了修改客户代码，如果要实现新产品直接修改工厂类，而不需要在原代码中修改，这样就降低了客户代码修改的可能性，更加容易扩展。

缺点：

增加新产品时还是需要修改工厂类的代码，违背了“开闭原则”。

1.2.2.4 扩展

静态工厂

在开发中也有一部分人将工厂类中的创建对象的功能定义为静态的，这个就是静态工厂模式，它也不是23种设计模式中的。代码如下：

public class SimpleCoffeeFactory {

    public static Coffee createCoffee(String type) {
        Coffee coffee = null;
        if("americano".equals(type)) {
            coffee = new AmericanoCoffee();
        } else if("latte".equals(type)) {
            coffee = new LatteCoffee();
        }
        return coffe;
    }
}

1.2.3 工厂方法模式

针对上例中的缺点，使用工厂方法模式就可以完美的解决，完全遵循开闭原则。

1.2.3.1 概念

定义一个用于创建对象的接口，让子类决定实例化哪个产品类对象。工厂方法使一个产品类的实例化延迟到其工厂的子类。

1.2.3.2 结构

工厂方法模式的主要角色：

• 抽象工厂（Abstract Factory）：提供了创建产品的接口，调用者通过它访问具体工厂的工厂方法来创建产品。
• 具体工厂（ConcreteFactory）：主要是实现抽象工厂中的抽象方法，完成具体产品的创建。
• 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能。
• 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它同具体工厂之间一一对应。

1.2.3.3 实现

使用工厂方法模式对上例进行改进，类图如下：

代码如下：

抽象工厂：

public interface CoffeeFactory {

    Coffee createCoffee();
}

具体工厂：

public class LatteCoffeeFactory implements CoffeeFactory {

    public Coffee createCoffee() {
        return new LatteCoffee();
    }
}

public class AmericanCoffeeFactory implements CoffeeFactory {

    public Coffee createCoffee() {
        return new AmericanCoffee();
    }
}

咖啡店类：

public class CoffeeStore {

    private CoffeeFactory factory;

    public CoffeeStore(CoffeeFactory factory) {
        this.factory = factory;
    }

    public Coffee orderCoffee(String type) {
        Coffee coffee = factory.createCoffee();
        coffee.addMilk();
        coffee.addsugar();
        return coffee;
    }
}

从以上的编写的代码可以看到，要增加产品类时也要相应地增加工厂类，不需要修改工厂类的代码了，这样就解决了简单工厂模式的缺点。

工厂方法模式是简单工厂模式的进一步抽象。由于使用了多态性，工厂方法模式保持了简单工厂模式的优点，而且克服了它的缺点。

1.2.3.4 优缺点

优点：

• 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程；
• 在系统增加新的产品时只需要添加具体产品类和对应的具体工厂类，无须对原工厂进行任何修改，满足开闭原则；

缺点：

• 每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类，这增加了系统的复杂度。

1.2.4 抽象工厂模式

前面介绍的工厂方法模式中考虑的是一类产品的生产

• 如畜牧场只养动物、电视机厂只生产电视机、传智播客只培养计算机软件专业的学生等。

这些工厂只生产同种类产品，同种类产品称为同等级产品，也就是说：工厂方法模式只考虑生产同等级的产品，但是在现实生活中许多工厂是综合型的工厂，能生产多等级（种类） 的产品

• 如电器厂既生产电视机又生产洗衣机或空调，大学既有软件专业又有生物专业等。

本节要介绍的抽象工厂模式将考虑多等级产品的生产，将同一个具体工厂所生产的位于不同等级的一组产品称为一个产品族，下图所示横轴是产品等级，也就是同一类产品；纵轴是产品族，也就是同一品牌的产品，同一品牌的产品产自同一个工厂。

• 同等级产品：就是同类别的产品，如：美式咖啡、拿铁咖啡。
• 同一产品族：就是一个工厂生产的不同类别的一系列产品，如：拿铁咖啡、意大利甜品。

1.2.4.1 概念

抽象工厂模式是一种为访问类提供一个创建一组相关或相互依赖对象的接口，且访问类无须指定所要产品的具体类就能得到同族的不同等级的产品的模式结构。

抽象工厂模式是工厂方法模式的升级版本，工厂方法模式只生产一个等级的产品，而抽象工厂模式可生产多个等级的产品。

1.2.4.2 结构

抽象工厂模式的主要角色如下：

• 抽象工厂（Abstract Factory）：提供了创建产品的接口，它包含多个创建产品的方法，可以创建多个不同等级的产品。
• 具体工厂（Concrete Factory）：主要是实现抽象工厂中的多个抽象方法，完成具体产品的创建。
• 抽象产品（Product）：定义了产品的规范，描述了产品的主要特性和功能，抽象工厂模式有多个抽象产品。
• 具体产品（ConcreteProduct）：实现了抽象产品角色所定义的接口，由具体工厂来创建，它 同具体工厂之间是多对一的关系。

1.2.4.3 实现

现咖啡店业务发生改变，不仅要生产咖啡还要生产甜点，如提拉米苏、抹茶慕斯等.

要是按照工厂方法模式，需要定义提拉米苏类、抹茶慕斯类、提拉米苏工厂、抹茶慕斯工厂、甜点工厂类，很容易发生类爆炸情况。

• 拿铁咖啡、美式咖啡是一个产品等级，都是咖啡；

• 提拉米苏、抹茶慕斯也是一个产品等级；

• 拿铁咖啡和提拉米苏是同一产品族（也就是都属于意大利风味），美式咖啡和抹茶慕斯是同一产品族（也就是都属于美式风味）。

所以这个案例可以使用抽象工厂模式实现。类图如下：

实体类：咖啡抽象类、甜品抽象类、美式咖啡、拿铁咖啡、提拉米苏、抹茶慕斯，和之前一样。

抽象工厂：

/**
 * 甜品工厂
 */
public interface DessertFactory {
    // 生产咖啡的功能
    Coffee createCoffee();
    // 生产甜品的功能
    Dessert createDessert();
}

具体工厂：

/**
 * 意大利风味的甜品工厂
 * 生产拿铁咖啡和提拉米苏甜品
 */
public class ItalyDessertFactory implements DessertFactory {
    public Coffee createCoffee() {
        return new LatteCoffee();
    }
    public Dessert createDessert() {
        return new Trimisu();
    }
}

/**
 * 美式风味的甜品工厂
 * 生产美式咖啡和抹茶慕斯
 */
public class AmericanDessertFactory implements DessertFactory {
    public Coffee createCoffee() {
        return new AmericanCoffee();
    }
    public Dessert createDessert() {
        return new MatchaMousse();
    }
}

测试类：

public class Client {
    public static void main(String[] args) {
        // 创建的是意大利风味甜品工厂对象
        ItalyDessertFactory factory = new ItalyDessertFactory();
        // 获取拿铁咖啡和提拉米苏甜品
        Coffee coffee = factory.createCoffee();
        Dessert dessert = factory.createDessert();
        dessert.show();
    }
}

如果要加同一个产品族的话，只需要再加一个对应的工厂类即可，不需要修改其他的类。

1.2.4.4 优缺点

优点：

当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。

缺点：

当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。

1.2.4.5 使用场景

• 当需要创建的对象是一系列相互关联或相互依赖的产品族时，如电器工厂中的电视机、洗衣机、空调等。

• 系统中有多个产品族，但每次只使用其中的某一族产品。如有人只喜欢穿某一个品牌的衣服和鞋。

• 系统中提供了产品的类库，且所有产品的接口相同，客户端不依赖产品实例的创建细节和内部结构。

如：输入法换皮肤，一整套一起换。生成不同操作系统的程序。

1.2.5 模式扩展

简单工厂+配置文件解除耦合

可以通过工厂模式+配置文件的方式解除工厂对象和产品对象的耦合。

在工厂类中加载配置文件中的全类名，并创建对象进行存储，客户端如果需要对象，直接进行获取即可。

实现代码：

第一步：定义配置文件

为了演示方便，我们使用properties文件作为配置文件，名称为bean.properties

american=com.itheima.pattern.factory.config_factory.AmericanCoffee
latte=com.itheima.pattern.factory.config_factory.LatteCoffee

第二步：改进工厂类

public class CoffeeFactory {
    // 加载配置文件，获取配置文件中配置的全类名，并创建该类的对象进行存储
    // 1,定义容器对象存储咖啡对象
    private static HashMap<String, Coffee> map = new HashMap<>();

    // 2,加载配置文件，只需要加载一次
    static {
        // 2.1 创建Properties对象
        Properties p = new Properties();
        // 2.2 调用p对象中的load方法进行配置文件的加载
        InputStream is = CoffeeFactory.class.getClassLoader().getResourceAsStream("bean.properties");
        try {
            p.load(is);
            // 从p集合中获取全类名并创建对象
            Set<Object> keys = p.keySet();
            for (Object key : keys) {
                String className = p.getProperty((String) key);
                // 通过反射技术创建对象
                Class clazz = Class.forName(className);
                Coffee coffee = (Coffee) clazz.newInstance();
                // 将名称和对象存储到容器中
                map.put((String) key, coffee);
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    //根据名称获取对象
    public static Coffee createCoffee(String name) {
        return map.get(name);
    }
}

静态成员变量用来存储创建的对象，键存储的是名称，值存储的是对应的对象，

而读取配置文件以及创建对象写在静态代码块中，目的就是只需要执行一次。

1.2.6 JDK源码解析-Collection.iterator方法

public class Demo {
    public static void main(String[] args) {
        List<String> list = new ArrayList<>();
        list.add("令狐冲");
        list.add("风清扬");
        list.add("任我行");

        //获取迭代器对象
        Iterator<String> it = list.iterator();
        //使用迭代器遍历
        while(it.hasNext()) {
            String ele = it.next();
            System.out.println(ele);
        }
    }
}

在单列集合获取迭代器的方法就使用到了工厂方法模式。我们看通过类图看看结构：

• Collection接口是抽象工厂类，ArrayList是具体的工厂类；

• Iterator接口是抽象商品类，ArrayList类中的Iter内部类是具体的商品类。

• 在具体的工厂类中iterator()方法创建具体的商品类的对象。

DateForamt类中的getInstance()方法使用的是工厂模式；

Calendar类中的getInstance()方法使用的是工厂模式；

1.3 原型模式

1.3.1 概述

用一个已经创建的实例作为原型，通过复制该原型对象来创建一个和原型对象相同的新对象。

1.3.2 结构

原型模式包含如下角色：

• 抽象原型类：规定了具体原型对象必须实现的的 clone() 方法。
• 具体原型类：实现抽象原型类的 clone() 方法，它是可被复制的对象。
• 访问类：使用具体原型类中的 clone() 方法来复制新的对象。

接口类图如下：

1.3.3 实现

原型模式的克隆分为浅克隆和深克隆。

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址。

深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。

Java中的Object类中提供了 clone() 方法来实现浅克隆。

Java中的Cloneable 接口是上面的类图中的抽象原型类，而实现了Cloneable接口的子实现类就是具体的原型类。

Realizetype（具体的原型类）：

public class Realizetype implements Cloneable {

    public Realizetype() {
        System.out.println("具体的原型对象创建完成！");
    }

    @Override
    protected Realizetype clone() throws CloneNotSupportedException {
        System.out.println("具体原型复制成功！");
        return (Realizetype) super.clone();
    }
}

PrototypeTest（测试访问类）：

public class PrototypeTest {
    public static void main(String[] args) throws CloneNotSupportedException {
        Realizetype r1 = new Realizetype();
        Realizetype r2 = r1.clone();
        System.out.println("对象r1和r2是同一个对象？" + (r1 == r2));
    }
}

运行结果：clone 原型对象的时候，不会调用构造方法，因为该对象不是通过 new 创建的

具体的原型对象创建完成！
具体原型复制成功！
对象r1和r2是同一个对象？false

1.3.4 案例

[例] 用原型模式生成“三好学生”奖状

同一学校的“三好学生”奖状除了获奖人姓名不同，其他都相同，可以使用原型模式复制多个“三好学生”奖状出来，然后在修改奖状上的名字即可。

类图如下：

代码如下：

//奖状类
public class Citation implements Cloneable {
    private String name;

    public void setName(String name) {
        this.name = name;
    }

    public String getName() {
        return (this.name);
    }

    public void show() {
        System.out.println(name + "同学：在2020学年第一学期中表现优秀，被评为三好学生。特发此状！");
    }

    @Override
    public Citation clone() throws CloneNotSupportedException {
        return (Citation) super.clone();
    }
}

//测试访问类
public class CitationTest {
    public static void main(String[] args) throws CloneNotSupportedException {
        Citation c1 = new Citation();
        c1.setName("张三");

        //复制奖状
        Citation c2 = c1.clone();
        //将奖状的名字修改李四
        c2.setName("李四");

        c1.show();
        c2.show();
    }
}

1.3.5 使用场景

以下两种情况，可以使用原型模式快捷的创建对象：

• 对象的创建非常复杂，可以使用原型模式快捷的创建对象。
• 性能和安全要求比较高。

1.3.6 扩展（深克隆）

将上面的“三好学生”奖状的案例中Citation类的name属性修改为Student类型的属性。代码如下：

//奖状类
public class Citation implements Cloneable {
    private Student stu;

    public Student getStu() {
        return stu;
    }

    public void setStu(Student stu) {
        this.stu = stu;
    }

    void show() {
        System.out.println(stu.getName() + "同学：在2020学年第一学期中表现优秀，被评为三好学生。特发此状！");
    }

    @Override
    public Citation clone() throws CloneNotSupportedException {
        return (Citation) super.clone();
    }
}

//学生类
public class Student {
    private String name;
    private String address;

    public Student(String name, String address) {
        this.name = name;
        this.address = address;
    }

    public Student() {
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getAddress() {
        return address;
    }

    public void setAddress(String address) {
        this.address = address;
    }
}

//测试类
public class CitationTest {
    public static void main(String[] args) throws CloneNotSupportedException {

        Citation c1 = new Citation();
        Student stu = new Student("张三", "西安");
        c1.setStu(stu);

        //复制奖状
        Citation c2 = c1.clone();
        //获取c2奖状所属学生对象
        Student stu1 = c2.getStu();
        stu1.setName("李四");

        //判断stu对象和stu1对象是否是同一个对象
        System.out.println("stu和stu1是同一个对象？" + (stu == stu1));

        c1.show();
        c2.show();
    }
}

运行结果：stu1 和 stu2 是同一个对象

st1和stu2是否同一个对象？true
李四同学：在2020学年第一学期中表现优秀，被评为三好学生。特发此状！
李四同学：在2020学年第一学期中表现优秀，被评为三好学生。特发此状！

stu1 和 stu2 是同一个对象，就会产生将 stu1 中 name 属性值改为 “李四”，两个 Citation 对象中显示的都是李四。

这就是浅克隆的效果，对具体原型类（Citation）中的引用类型的属性进行引用的复制。

这种情况需要使用深克隆，而进行深克隆需要使用对象流。

说明：

​ stu对象和stu1对象是同一个对象，就会产生将stu1对象中name属性值改为“李四”，两个Citation（奖状）对象中显示的都是李四。这就是浅克隆的效果，对具体原型类（Citation）中的引用类型的属性进行引用的复制。这种情况需要使用深克隆，而进行深克隆需要使用对象流。代码如下：

public class CitationTest1 {
    public static void main(String[] args) throws Exception {
        Citation c1 = new Citation();
        Student stu = new Student("张三", "西安");
        c1.setStu(stu);

        //创建对象输出流对象
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("C:\\Users\\Think\\Desktop\\b.txt"));
        //将c1对象写出到文件中
        oos.writeObject(c1);
        oos.close();

        //创建对象出入流对象
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("C:\\Users\\Think\\Desktop\\b.txt"));
        //读取对象
        Citation c2 = (Citation) ois.readObject();
        //获取c2奖状所属学生对象
        Student stu1 = c2.getStu();
        stu1.setName("李四");

        //判断stu对象和stu1对象是否是同一个对象
        System.out.println("stu和stu1是同一个对象？" + (stu == stu1));

        c1.show();
        c2.show();
    }
}

运行结果为：

注意：Citation类和Student类必须实现Serializable接口，否则会抛NotSerializableException异常。

实现 1：文件流 + 对象流

学生类（Student）同上，但是要实现 Serializable 接口。

奖状类（Citation）实现 Serializable 接口，定义一个 deepClone 方法，通过文件输出流流和对象流实现深克隆。

// 1 所有对象都实现序列化的接口
// 2 自定义一个深度克隆方法deepClone, 通过文件流和对象流的方式实现对象的深度拷贝
public Citation deepClone() throws Exception {
  try (ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("a.txt"));
       ObjectInputStream ois = new ObjectInputStream(new FileInputStream("a.txt"));) {
    oos.writeObject(this);
    Citation citation = (Citation) ois.readObject();
    return citation;
  }
}

实现 2：字节数组流 + 对象流

学生类（Student）同上，实现 Serializable 接口。

奖状类（Citation）实现 Serializable 接口，定义一个 deepClone 方法，通过字节数组流和对象流实现深克隆。

// 1 所有对象都实现序列化的接口
// 2 自定义一个深度克隆方法deepClone, 通过字节数组流和对象流的方式实现对象的深度拷贝
public Citation deepClone2() throws Exception {
  try (ByteArrayOutputStream bos = new ByteArrayOutputStream();
       ObjectOutputStream oos = new ObjectOutputStream(bos)) {
    oos.writeObject(this);
    ByteArrayInputStream bis = new ByteArrayInputStream(bos.toByteArray());
    ObjectInputStream ois = new ObjectInputStream(bis);
    return (Citation) ois.readObject();
  }
}

测试

以上两种方法都可以实现深克隆：

public class CitationTest {
    public static void main(String[] args) throws Exception {
        // 原型对象
        Citation c1 = new Citation();
        Student stu1 = new Student("张三");
        c1.setStu(stu1);

        // 复制奖状并修改名字
        Citation c2 = c1.deepClone();
        Student stu2 = c2.getStu();
        stu2.setName("李四");

        // 判断stu1对象和stu2对象是否是同一个对象
        System.out.println("st1和stu2是否同一个对象？" + (stu1 == stu2));

        c1.show();
        c2.show();
    }
}

运行结果：

st1和stu2是否同一个对象？false
张三同学：在2020学年第一学期中表现优秀，被评为三好学生。特发此状！
李四同学：在2020学年第一学期中表现优秀，被评为三好学生。特发此状！

1.4 建造者模式

1.4.1 概述

将一个复杂对象的构建与表示分离，使得同样的构建过程可以创建不同的表示。

这个模式适用于：某个对象的构建过程复杂的情况。

• 将部件的构造与装配分离，由 Builder 负责构造，Director 进行装配，实现了构建和装配的解耦。
• 不同的构建器，相同的装配，可以做出不同的对象。
• 相同的构建器，不同的装配顺序，也可以做出不同的对象。
• 用户只需要指定复杂对象的类型就可以得到该对象，而无须知道其内部的具体构造细节。

1.4.2 结构

建造者（Builder）模式包含如下角色：

• 抽象建造者类（Builder）：这个接口规定要实现复杂对象的那些部分的创建，并不涉及具体的部件对象的创建。

• 具体建造者类（ConcreteBuilder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。在构造过程完成后，提供产品的实例。

• 产品类（Product）：要创建的复杂对象。

• 指挥者类（Director）：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。

类图如下：

1.4.3 实例

创建共享单车

生产自行车是一个复杂的过程，它包含了车架，车座等组件的生产：

• 车架有碳纤维，铝合金等材质。
• 车座有橡胶，真皮等材质。

对于自行车的生产就可以使用建造者模式，类图如下：

• Bike 是产品，包含车架，车座等组件。
• Builder 是抽象建造者。
• MobikeBuilder 和 OfoBuilder 是具体的建造者。
• Director 是指挥者。

具体的代码如下：产品对象：自行车

//自行车类
public class Bike {
    private String frame;
    private String seat;

    public String getFrame() {
        return frame;
    }

    public void setFrame(String frame) {
        this.frame = frame;
    }

    public String getSeat() {
        return seat;
    }

    public void setSeat(String seat) {
        this.seat = seat;
    }
}

// 抽象 builder 类
public abstract class Builder {

    protected Bike mBike = new Bike();

    public abstract void buildFrame();
    public abstract void buildSeat();
    public abstract Bike createBike();
}

//摩拜单车Builder类
public class MobikeBuilder extends Builder {

    @Override
    public void buildFrame() {
        mBike.setFrame("铝合金车架");
    }

    @Override
    public void buildSeat() {
        mBike.setSeat("真皮车座");
    }

    @Override
    public Bike createBike() {
        return mBike;
    }
}

//ofo单车Builder类
public class OfoBuilder extends Builder {

    @Override
    public void buildFrame() {
        mBike.setFrame("碳纤维车架");
    }

    @Override
    public void buildSeat() {
        mBike.setSeat("橡胶车座");
    }

    @Override
    public Bike createBike() {
        return mBike;
    }
}

//指挥者类
public class Director {
    private Builder mBuilder;

    public Director(Builder builder) {
        mBuilder = builder;
    }

    public Bike construct() {
        mBuilder.buildFrame();
        mBuilder.buildSeat();
        return mBuilder.createBike();
    }
}

//测试类
public class Client {
    public static void main(String[] args) {
        showBike(new OfoBuilder());
        showBike(new MobikeBuilder());
    }
    private static void showBike(Builder builder) {
        Director director = new Director(builder);
        Bike bike = director.construct();
        System.out.println(bike.getFrame());
        System.out.println(bike.getSeat());
    }
}

注意：

上面示例是 Builder模式的常规用法，指挥者类 Director 在建造者模式中具有很重要的作用，它用于指导具体构建者如何构建产品，控制调用先后次序，并向调用者返回完整的产品类.

但是有些情况下需要简化系统结构，可以把指挥者类和抽象建造者进行结合

// 抽象 builder 类
public abstract class Builder {

    protected Bike mBike = new Bike();

    public abstract void buildFrame();
    public abstract void buildSeat();
    public abstract Bike createBike();
    
    public Bike construct() {
        this.buildFrame();
        this.BuildSeat();
        return this.createBike();
    }
}

说明：

这样做确实简化了系统结构，但同时也加重了抽象建造者类的职责，也不是太符合单一职责原则，

如果construct() 过于复杂，建议还是封装到 Director 中。

1.1.4 优缺点

优点：

• 建造者模式的封装性很好。使用建造者模式可以有效的封装变化，在使用建造者模式的场景中，一般产品类和建造者类是比较稳定的，因此，将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
• 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解耦，使得相同的创建过程可以创建不同的产品对象。
• 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中，使得创建过程更加清晰，也更方便使用程序来控制创建过程。
• 建造者模式很容易进行扩展。如果有新的需求，通过实现一个新的建造者类就可以完成，基本上不用修改之前已经测试通过的代码，因此也就不会对原有功能引入风险。符合开闭原则。

缺点：

• 造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异性很大，则不适合使用建造者模式，因此其使用范围受到一定的限制。

1.4.5 使用场景

建造者（Builder）模式创建的是复杂对象，其产品的各个部分经常面临着剧烈的变化，但将它们组合在一起的算法却相对稳定，所以它通常在以下场合使用。

• 创建的对象较复杂，由多个部件构成，各部件面临着复杂的变化，但构件间的建造顺序是稳定的。
• 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式，即产品的构建过程和最终的表示是独立的。

1.4.6 模式扩展

建造者模式除了上面的用途外，在开发中还有一个常用的使用方式，就是当一个类构造器需要传入很多参数时，如果创建这个类的实例，代码可读性会非常差，而且很容易引入错误，此时就可以利用建造者模式进行重构。

重构前代码如下：

public class Phone {
    private String cpu;
    private String screen;
    private String memory;
    private String mainboard;

    public Phone(String cpu, String screen, String memory, String mainboard) {
        this.cpu = cpu;
        this.screen = screen;
        this.memory = memory;
        this.mainboard = mainboard;
    }

    public String getCpu() {
        return cpu;
    }

    public void setCpu(String cpu) {
        this.cpu = cpu;
    }

    public String getScreen() {
        return screen;
    }

    public void setScreen(String screen) {
        this.screen = screen;
    }

    public String getMemory() {
        return memory;
    }

    public void setMemory(String memory) {
        this.memory = memory;
    }

    public String getMainboard() {
        return mainboard;
    }

    public void setMainboard(String mainboard) {
        this.mainboard = mainboard;
    }

    @Override
    public String toString() {
        return "Phone{" +
                "cpu='" + cpu + '\'' +
                ", screen='" + screen + '\'' +
                ", memory='" + memory + '\'' +
                ", mainboard='" + mainboard + '\'' +
                '}';
    }
}

public class Client {
    public static void main(String[] args) {
        //构建Phone对象
        Phone phone = new Phone("intel","三星屏幕","金士顿","华硕");
        System.out.println(phone);
    }
}

上面在客户端代码中构建Phone对象，传递了四个参数，如果参数更多呢？代码的可读性及使用的成本就是比较高。

重构后代码：

public class Phone {

    private String cpu;
    private String screen;
    private String memory;
    private String mainboard;

    private Phone(Builder builder) {
        cpu = builder.cpu;
        screen = builder.screen;
        memory = builder.memory;
        mainboard = builder.mainboard;
    }

    public static final class Builder {
        private String cpu;
        private String screen;
        private String memory;
        private String mainboard;

        public Builder() {}

        public Builder cpu(String val) {
            cpu = val;
            return this;
        }
        public Builder screen(String val) {
            screen = val;
            return this;
        }
        public Builder memory(String val) {
            memory = val;
            return this;
        }
        public Builder mainboard(String val) {
            mainboard = val;
            return this;
        }
        public Phone build() {
            return new Phone(this);}
    }
    @Override
    public String toString() {
        return "Phone{" +
                "cpu='" + cpu + '\'' +
                ", screen='" + screen + '\'' +
                ", memory='" + memory + '\'' +
                ", mainboard='" + mainboard + '\'' +
                '}';
    }
}

public class Client {
    public static void main(String[] args) {
        Phone phone = new Phone.Builder()
                .cpu("intel")
                .mainboard("华硕")
                .memory("金士顿")
                .screen("三星")
                .build();
        System.out.println(phone);
    }
}

重构后的代码在使用起来更方便，某种程度上也可以提高开发效率。从软件设计上，对程序员的要求比较高。

1.5 创建者模式对比

1.5.1 工厂方法模式VS建造者模式

两者对比：

• 工厂方法模式注重的是整体对象的创建方式

• 建造者模式注重的是部件构建的过程，意在通过一步一步地精确构造创建出一个复杂的对象。

举个简单例子来说明两者的差异，如要制造一个超人：

• 如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人。
• 如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。

1.5.2 抽象工厂模式VS建造者模式

两者对比：

• 抽象工厂模式实现对产品家族的创建，一个产品家族是这样的一系列产品：具有不同分类维度的产品组合，采用抽象工厂模式则是不需要关心构建过程，只关心什么产品由什么工厂生产即可。

• 建造者模式则是要求按照指定的蓝图建造产品，它的主要目的是通过组装零配件而产生一个新产品。

简单的例子：

• 如果将抽象工厂模式看成汽车配件生产工厂，生产一个产品族的产品，
• 那么建造者模式就是一个汽车组装工厂，通过对部件的组装可以返回一辆完整的汽车。