设计模式学习笔记

学习时间：2022年7月14日

学习来源：黑马

1 概述

1.1 产生背景

“设计模式”最初并不是出现在软件设计中，而是被用于建筑领域的设计中。

1977年美国著名建筑大师、加利福尼亚大学伯克利分校环境结构中心主任克里斯托夫·亚历山大（Christopher Alexander）在他的著作《建筑模式语言：城镇、建筑、构造》中描述了一些常见的建筑设计问题，并提出了 253 种关于对城镇、邻里、住宅、花园和房间等进行设计的基本模式。

1990年软件工程界开始研讨设计模式的话题，后来召开了多次关于设计模式的研讨会。直到1995 年，艾瑞克·伽马（ErichGamma）、理査德·海尔姆（Richard Helm）、拉尔夫·约翰森（Ralph Johnson）、约翰·威利斯迪斯（John Vlissides）等 4 位作者合作出版了《设计模式：可复用面向对象软件的基础》一书，在此书中收录了 23 个设计模式，这是设计模式领域里程碑的事件，导致了软件设计模式的突破。这 4 位作者在软件开发领域里也以他们的“四人组”（Gang of Four，GoF）著称。

1.2 概念

软件设计模式（Software Design Pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它描述了在软件设计过程中的一些不断重复发生的问题，以及该问题的解决方案。也就是说，它是解决特定问题的一系列套路，是前辈们的代码设计经验的总结，具有一定的普遍性，可以反复使用。

1.3 分类

创建型模式：用于描述“怎样创建对象”，它的主要特点是“将对象的创建与使用分离”。GoF（四人组）书中提供了单例、原型、工厂方法、抽象工厂、建造者等 5 种创建型模式。5
结构型模式：用于描述如何将类或对象按某种布局组成更大的结构，GoF（四人组）书中提供了代理、适配器、桥接、装饰、外观、享元、组合等 7 种结构型模式。7
行为型模式：用于描述类或对象之间怎样相互协作共同完成单个对象无法单独完成的任务，以及怎样分配职责。GoF（四人组）书中提供了模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器等 11 种行为型模式。11

2 UML类图

2.1 概述

统一建模语言（Unified Modeling Language，UML）是用来设计软件的可视化建模语言。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。

UML 从目标系统的不同角度出发，定义了用例图、类图、对象图、状态图、活动图、时序图、协作图、构件图、部署图等 9 种图。

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性的信息。类图是面向对象建模的主要组成部分。

2.2 表示法

2.2.1 类的表示方式

在UML类图中，类使用包含类名、属性(field) 和方法(method) 且带有分割线的矩形来表示，比如下图表示一个Employee类，它包含name,age和address这3个属性，以及work()方法。

属性/方法名称前加的加号和减号表示了这个属性/方法的可见性，UML类图中表示可见性的符号有三种：

+：表示public
-：表示private
#：表示protected

属性的完整表示方式是： 可见性名称：类型 [ = 缺省值]

方法的完整表示方式是： 可见性名称(参数列表) [ ：返回类型]

2.2.2 类之间关系的表示方式

① 关联关系

关联关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。关联关系是类与类之间最常用的一种关系，分为一般关联关系、聚合关系和组合关系。

一般关联又可以分为单向关联，双向关联，自关联。

单向关联

在UML类图中单向关联用一个带箭头的实线表示。上图表示每个顾客都有一个地址，这通过让Customer类持有一个类型为Address的成员变量类实现。

双向关联

从上图中我们很容易看出，所谓的双向关联就是双方各自持有对方类型的成员变量。

在UML类图中，双向关联用一个不带箭头的直线表示。上图中在Customer类中维护一个List<Product>，表示一个顾客可以购买多个商品；在Product类中维护一个Customer类型的成员变量表示这个产品被哪个顾客所购买。

自关联

自关联在UML类图中用一个带有箭头且指向自身的线表示。上图的意思就是Node类包含类型为Node的成员变量，也就是“自己包含自己”。

② 聚合关系

聚合关系是关联关系的一种，是强关联关系，是整体和部分之间的关系。

聚合关系也是通过成员对象来实现的，其中成员对象是整体对象的一部分，但是成员对象可以脱离整体对象而独立存在。例如，学校与老师的关系，学校包含老师，但如果学校停办了，老师依然存在。

在 UML 类图中，聚合关系可以用带空心菱形的实线来表示，菱形指向整体。下图所示是大学和教师的关系图：

③ 组合关系

组合表示类之间的整体与部分的关系，但它是一种更强烈的聚合关系。

在组合关系中，整体对象可以控制部分对象的生命周期，一旦整体对象不存在，部分对象也将不存在，部分对象不能脱离整体对象而存在。例如，头和嘴的关系，没有了头，嘴也就不存在了。

在 UML 类图中，组合关系用带实心菱形的实线来表示，菱形指向整体。下图所示是头和嘴的关系图：

④ 依赖关系

依赖关系是一种使用关系，它是对象之间耦合度最弱的一种关联方式，是临时性的关联。在代码中，某个类的方法通过局部变量、方法的参数或者对静态方法的调用来访问另一个类（被依赖类）中的某些方法来完成一些职责。

在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。下图所示是司机和汽车的关系图，司机驾驶汽车：

⑤ 继承关系

继承关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系。

在 UML 类图中，泛化关系用带空心三角箭头的实线来表示，箭头从子类指向父类。在代码实现时，使用面向对象的继承机制来实现泛化关系。例如，Student 类和 Teacher 类都是 Person 类的子类，其类图如下图所示：

⑥ 实现关系

实现关系是接口与实现类之间的关系。在这种关系中，类实现了接口，类中的操作实现了接口中所声明的所有的抽象操作。

在 UML 类图中，实现关系使用带空心三角箭头的虚线来表示，箭头从实现类指向接口。例如，汽车和船实现了交通工具。

3 软件设计原则

在软件开发中，为了提高软件系统的可维护性和可复用性，增加软件的可扩展性和灵活性，程序员要尽量根据6条原则来开发程序，从而提高软件开发效率、节约软件开发成本和维护成本。

3.1 开闭原则

对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。

想要达到这样的效果，我们需要使用接口和抽象类。

因为抽象灵活性好，适应性广，只要抽象的合理，可以基本保持软件架构的稳定。而软件中易变的细节可以从抽象派生来的实现类来进行扩展，当软件需要发生变化时，只需要根据需求重新派生一个实现类来扩展就可以了。

下面以 搜狗输入法 的皮肤为例介绍开闭原则的应用。

【例】搜狗输入法 的皮肤设计。

分析：搜狗输入法 的皮肤是输入法背景图片、窗口颜色和声音等元素的组合。用户可以根据自己的喜爱更换自己的输入法的皮肤，也可以从网上下载新的皮肤。这些皮肤有共同的特点，可以为其定义一个抽象类（AbstractSkin），而每个具体的皮肤（DefaultSpecificSkin和HeimaSpecificSkin）是其子类。用户窗体可以根据需要选择或者增加新的主题，而不需要修改原代码，所以它是满足开闭原则的。

代码演示

public abstract class AbstractSkin {
    // 显示的方法
    public abstract void display();
}

public class DefaultSkin  extends AbstractSkin{
    @Override
    public void display() {
        System.out.println("默认皮肤...");
    }
}

public class HongyiSkin extends AbstractSkin{
    @Override
    public void display() {
        System.out.println("Hongyi皮肤...");
    }
}

@Data
public class SougouInput {
    private AbstractSkin skin;

    public void display() {
        skin.display();
    }
}

用户使用时：

public class Client {
    public static void main(String[] args) {
        // 1.创建搜狗输入法的对象
        SougouInput input = new SougouInput();
        // 2.创建皮肤对象
        DefaultSkin defaultSkin = new DefaultSkin();
        HongyiSkin hongyiSkin = new HongyiSkin();
        // 3.将皮肤设置到输入法中
        input.setSkin(defaultSkin);
        // 4.显示皮肤
        input.display();
    }
}

3.2 里氏代换原则

里氏代换原则是面向对象设计的基本原则之一。

里氏代换原则：任何基类可以出现的地方，子类一定可以出现。通俗理解：子类可以扩展父类的功能，但不能改变父类原有的功能。换句话说，子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。如果确实要重写父类的方法，可以将父类的方法定义为抽象方法。

如果通过重写父类的方法来完成新的功能，这样写起来虽然简单，但是整个继承体系的可复用性会比较差，特别是运用多态比较频繁时，程序运行出错的概率会非常大。

下面看一个里氏替换原则中经典的一个例子

【例】正方形不是长方形。

在数学领域里，正方形毫无疑问是长方形，它是一个长宽相等的长方形。所以，我们开发的一个与几何图形相关的软件系统，就可以顺理成章的让正方形继承自长方形。

3.3 依赖倒转原则

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。简单的说就是要求对抽象进行编程，不要对实现进行编程，这样就降低了客户与实现模块间的耦合。

下面看一个例子来理解依赖倒转原则

【例】组装电脑

现要组装一台电脑，需要配件cpu，硬盘，内存条。只有这些配置都有了，计算机才能正常的运行。选择cpu有很多选择，如Intel，AMD等，硬盘可以选择希捷，西数等，内存条可以选择金士顿，海盗船等。

3.4 接口隔离原则

客户端不应该被迫依赖于它不使用的方法；一个类对另一个类的依赖应该建立在最小的接口上。

下面看一个例子来理解接口隔离原则

【例】安全门案例

我们需要创建一个黑马品牌的安全门，该安全门具有防火、防水、防盗的功能。可以将防火，防水，防盗功能提取成一个接口，形成一套规范。类图如下：

上面的设计我们发现了它存在的问题，黑马品牌的安全门具有防盗，防水，防火的功能。现在如果我们还需要再创建一个传智品牌的安全门，而该安全门只具有防盗、防水功能呢？很显然如果实现SafetyDoor接口就违背了接口隔离原则，那么我们如何进行修改呢？看如下类图：

3.5 迪米特法则

迪米特法则又叫最少知识原则。

只和你的直接朋友交谈，不跟“陌生人”说话（Talk only to your immediate friends and not to strangers）。

其含义是：如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。其目的是降低类之间的耦合度，提高模块的相对独立性。

迪米特法则中的“朋友”是指：当前对象本身、当前对象的成员对象、当前对象所创建的对象、当前对象的方法参数等，这些对象同当前对象存在关联、聚合或组合关系，可以直接访问这些对象的方法。

下面看一个例子来理解迪米特法则

【例】明星与经纪人的关系实例

明星由于全身心投入艺术，所以许多日常事务由经纪人负责处理，如和粉丝的见面会，和媒体公司的业务洽淡等。这里的经纪人是明星的朋友，而粉丝和媒体公司是陌生人，所以适合使用迪米特法则。

类图如下：

3.6 合成复用原则

合成复用原则是指：尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

通常类的复用分为继承复用和合成复用两种。

继承复用虽然有简单和易实现的优点，但它也存在以下缺点：

继承复用破坏了类的封装性。因为继承会将父类的实现细节暴露给子类，父类对子类是透明的，所以这种复用又称为“白箱”复用。
子类与父类的耦合度高。父类的实现的任何改变都会导致子类的实现发生变化，这不利于类的扩展与维护。
它限制了复用的灵活性。从父类继承而来的实现是静态的，在编译时已经定义，所以在运行时不可能发生变化。

采用组合或聚合复用时，可以将已有对象纳入新对象中，使之成为新对象的一部分，新对象可以调用已有对象的功能，它有以下优点：

它维持了类的封装性。因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用。
对象间的耦合度低。可以在类的成员位置声明抽象。
复用的灵活性高。这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象。

下面看一个例子来理解合成复用原则

【例】汽车分类管理程序

汽车按“动力源”划分可分为汽油汽车、电动汽车等；按“颜色”划分可分为白色汽车、黑色汽车和红色汽车等。如果同时考虑这两种分类，其组合就很多。类图如下：

从上面类图我们可以看到使用继承复用产生了很多子类，如果现在又有新的动力源或者新的颜色的话，就需要再定义新的类。我们试着将继承复用改为聚合复用看一下。

4 创建者模式

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节。

创建型模式分为：

单例模式
工厂方法模式
抽象工程模式
原型模式
建造者模式

4.1 单例设计模式

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

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

4.1.1 结构

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

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

4.1.2 实现

单例设计模式分类两种：

饿汉式：类加载（类的代码加载到内存）就会导致该单实例对象被创建，不存在线程安全问题
1. 静态变量
2. 静态代码块
3. 枚举
懒汉式：类加载不会导致该单实例对象被创建，而是首次使用该对象时才会创建，会存在线程安全问题
1. 线程不安全式
2. 线程安全式（加锁）
3. 双重检查锁
4. 静态内部类

① 饿汉式-方式1（静态变量方式）

public class Singleton {

    // 1.私有构造方法
    private Singleton() {};

    // 2.在本类中创建该类对象
    private static Singleton instance = new Singleton();

    // 3.提供一个公共的访问方式，让外界获取
    public static Singleton getInstance() {
        return instance;
    }
}

public class Test {
    public static void main(String[] args) {
        Singleton instance1 = Singleton.getInstance();
        Singleton instance2 = Singleton.getInstance();
        System.out.println(instance1 == instance2); // true
    }
}

该方式在成员位置声明Singleton类型的静态变量，并创建Singleton类的对象instance。instance对象是随着类的加载而创建的。如果该对象足够大的话，而一直没有使用就会造成内存的浪费。

② 饿汉式-方式2（静态代码块方式）

public class Singleton {
  // 1.私有构造方法
  private Singleton() {};

  // 2.声明Singleton类型的变量
  private static Singleton instance;

  // 3.在静态代码块中进行赋值
  static {
    instance = new Singleton();
  }

  // 4.提供一个公共的访问方式，让外界获取
  public static Singleton getInstance() {
    return instance;
  }
}

该方式在成员位置声明Singleton类型的静态变量，而对象的创建是在静态代码块中，也是随着类的加载而创建。所以和饿汉式的方式1基本上一样，当然该方式也存在内存浪费问题。

③ 懒汉式-方式1（线程不安全）

public class Singleton {
  // 1.私有构造方法
  private Singleton() {};

  // 2.声明Singleton类型的变量
  private static Singleton instance;

  // 3.对外提供访问方式
  public static Singleton getInstance() {
    // instance为null，说明还未被创建
    if (instance == null) {
      instance = new Singleton();
    }
    return instance;
  }
}

从上面代码我们可以看出该方式在成员位置声明Singleton类型的静态变量，并没有进行对象的赋值操作，那么什么时候赋值的呢？当调用getInstance()方法获取Singleton类的对象的时候才创建Singleton类的对象，这样就实现了懒加载的效果。但是，如果是多线程环境，会出现线程安全问题（第12行代码）。

④ 懒汉式-方式2（线程安全）

public class Singleton {
  // 1.私有构造方法
  private Singleton() {};

  // 2.声明Singleton类型的变量
  private static Singleton instance;

  // 3.对外提供访问方式
  public static synchronized Singleton getInstance() {
    // instance为null，说明还未被创建
    if (instance == null) {
      instance = new Singleton();
    }
    return instance;
  }
  
  // 或者：
  public static Singleton getInstance() {
    synchronized (Singleton.class) {
      if (instance == null) {
        instance = new Singleton();
      }
      return instance;
    }
  }
}

该方式也实现了懒加载效果，同时又解决了线程安全问题。但是在getInstance()方法上添加了synchronized关键字，导致该方法的执行效果特别低。从上面代码我们可以看出，其实就是在初始化instance的时候才会出现线程安全问题，一旦初始化完成就不存在了。

⑤ 懒汉式-方式3（双重检查锁）

对于 getInstance() 方法来说，绝大部分的操作都是读操作，读操作是线程安全的，所以我们没必让每个线程必须持有锁才能调用该方法，我们需要调整加锁的时机。由此也产生了一种新的实现模式：双重检查锁模式。

public class Singleton {
  // 1.私有构造方法
  private Singleton() {};

  // 2.声明变量
  private static Singleton instance;

  // 3.对外提供方法
  public static Singleton getInstance() {
    // 第一次判断，如果instance不为null，则不需要抢占锁，直接返回对象
    // 如果为null，则需要抢占锁来创建instance对象
    if (instance == null) {
      synchronized (Singleton.class) {
        // 第二次判断，优先抢占到锁的线程会通过if判断而创建instance对象
        // 后来的线程则不会通过if判断，直接跳转到21行返回
        if (instance == null) {
          instance = new Singleton();
        }
      }
    }
    return instance;
  }
}

双重检查锁模式是一种非常好的单例实现模式，解决了单例、性能、线程安全问题，上面的双重检测锁模式看上去完美无缺，其实是存在问题，在多线程的情况下，可能会出现空指针问题，出现问题的原因是JVM在实例化对象的时候会进行优化和指令重排序操作。

这个被忽略的问题在于 instance = new Singleton(); 这行代码并不是一个原子指令。

给 singleton 分配内存空间（堆内存）；
开始调用 Singleton 的构造函数等，来初始化 singleton；
将 singleton 对象指向分配的内存空间（执行完这步 singleton 就不是 null 了）。

这里需要留意一下 1-2-3 的顺序，因为存在指令重排序的优化，也就是说第 2 步和第 3 步的顺序是不能保证的，最终的执行顺序，可能是 1-2-3，也有可能是 1-3-2。

如果是 1-3-2，那么在第 3 步执行完以后，singleton 就不是 null 了，这时第 2 步并没有执行，singleton 对象未完成初始化，它的属性的值可能不是我们所预期的值（内存的随机值）。假设此时线程 2 进入 getInstance 方法，由于 singleton 已经不是 null 了，所以会通过第一重检查并直接返回instance对象，但其实这时的 singleton 并没有完成初始化，所以使用这个实例的时候会报错，详细流程如下图所示：

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

1	private static volatile Singleton instance;

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

⑥ 懒汉式-方式4（静态内部类方式）

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

public class Singleton {
    // 1.私有构造方法
    private Singleton() {};

    // 2.定义一个静态内部类
    private static class SingletonHolder {
        // 在内部类中声明并且初始化外部类的对象
        private static final Singleton INSTANCE = new Singleton();
    }
    
    // 3.提供对外方法
    public static Singleton getInstance() {
        return SingletonHolder.INSTANCE;
    }
}

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

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

⑦ 饿汉式-方式3（枚举）

枚举类实现单例模式是极力推荐的单例实现模式，因为枚举类型是线程安全的，并且只会装载一次，设计者充分的利用了枚举的这个特性来实现单例模式，枚举的写法非常简单，而且枚举类型是所用单例实现中唯一一种不会被破坏的单例实现模式。

1
2
3

public enum Singleton {
    INSTANCE;
}

public class test {
    public static void main(String[] args) {
        Singleton instance1 = Singleton.INSTANCE;
        Singleton instance2 = Singleton.INSTANCE;
        System.out.println(instance1 == instance2); // true
    }
}

4.1.3 问题

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

序列化和反序列化破坏单例模式

public class Test {
    public static void main(String[] args) throws Exception {
        writeObject2File();
        readObjectFromFile();
        readObjectFromFile();
    }

    // 从文件中读数据（对象）
    public static void readObjectFromFile() throws Exception {
        // 创建对象输入流对象
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("D:\\a.txt"));
        // 读取对象
        Singleton instance = (Singleton) ois.readObject();
        System.out.println(instance);
        // 释放资源
        ois.close();
    }

    // 向文件中写数据（对象）
    public static void writeObject2File() throws Exception {
        Singleton instance = Singleton.getInstance();
        // 创建对象输出流对象
        ObjectOutputStream oos = new ObjectOutputStream(new FileOutputStream("D:\\a.txt"));
        // 写入对象
        oos.writeObject(instance);
        // 释放资源
        oos.close();
    }
}

执行结果：

1 2	com.hongyi.pattern.singleton.demo7.Singleton@736e9adb com.hongyi.pattern.singleton.demo7.Singleton@6d21714c

instance对应的地址不同，是不同的对象，表明序列化和反序列化已经破坏了单例设计模式。

反射破坏单例模式

public class Test1 {
    public static void main(String[] args) throws NoSuchMethodException, InvocationTargetException, InstantiationException, IllegalAccessException {
        // 获取Singleton的字节码对象
        Class<Singleton> clazz = Singleton.class;
        // 获取无参构造器方法对象
        Constructor<Singleton> cons = clazz.getDeclaredConstructor();
        // 取消访问检查
        cons.setAccessible(true);
        // 创建Singleton对象
        Singleton singleton1 = cons.newInstance();
        Singleton singleton2 = cons.newInstance();
        System.out.println(singleton1 == singleton2); // false
    }
}

4.1.4 Runtime类

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

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

    public static Runtime getRuntime() {
        return currentRuntime;
    }

    /** Don't let anyone else instantiate this class */
    private Runtime() {}
    
    // 其余代码略
}

从上面源代码中可以看出Runtime类使用的是饿汉式（静态属性）方式来实现单例模式的。

4.2 工厂模式

4.2.1 概述

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

设计一个咖啡类（Coffee），并定义其两个子类（美式咖啡【AmericanCoffee】和拿铁咖啡【LatteCoffee】）；再设计一个咖啡店类（CoffeeStore），咖啡店具有点咖啡的功能。

具体类的设计如下：

需求实现

// 抽象类Coffee
public abstract class Coffee {

    public abstract String getName();

    // 加糖
    public void addSugar() {
        System.out.println("加糖");
    }

    // 加奶
    public void addMilk() {
        System.out.println("加奶");
    }
}

public class AmericanCoffee extends Coffee{
    @Override
    public String getName() {
        return "美式咖啡";
    }
}

public class LatteCaffe extends Coffee{
    @Override
    public String getName() {
        return "拿铁咖啡";
    }
}

// 咖啡店
public class CoffeeStore {
    public Coffee orderCoffee(String type) {
        Coffee coffee = null;
        if ("american".equals(type)) {
            coffee = new AmericanCoffee();
        } else if ("latte".equals(type)) {
            coffee = new LatteCaffe();
        } else {
            throw new RuntimeException("对不起，没有您点的咖啡");
        }
        coffee.addMilk();
        coffee.addSugar();
        return coffee;
    }
}

// 测试类
public class Test {
    public static void main(String[] args) {
        CoffeeStore store = new CoffeeStore();
        Coffee coffee = store.orderCoffee("latte");
        System.out.println(coffee.getName());
    }
}

打印结果：

1
2
3

加奶
加糖
拿铁咖啡

在java中，万物皆对象，这些对象都需要创建，如果创建的时候直接new该对象，就会对该对象耦合严重，假如我们要更换对象，所有new对象的地方都需要修改一遍，这显然违背了软件设计的开闭原则。如果我们使用工厂来生产对象，我们就只和工厂打交道就可以了，彻底和对象解耦，如果要更换对象，直接在工厂里更换该对象即可，达到了与对象解耦的目的；所以说，工厂模式最大的优点就是：解耦。

4.2.2 简单工厂模式

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

① 结构

简单工厂包含如下角色：

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

② 实现

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

实现

public class SimpleCoffeeFactory {

    public Coffee createCoffee(String type) {
        Coffee coffee = null;
        if ("american".equals(type)) {
            coffee = new AmericanCoffee();
        } else if ("latte".equals(type)) {
            coffee = new LatteCaffe();
        } else {
            throw new RuntimeException("对不起，没有您点的咖啡");
        }
        return coffee;
    }
}

public class CoffeeStore {
    public Coffee orderCoffee(String type) {
        SimpleCoffeeFactory factory = new SimpleCoffeeFactory();
        // 从工厂中获取Coffee对象
        Coffee coffee = factory.createCoffee(type);
        coffee.addMilk();
        coffee.addSugar();
        return coffee;
    }
}

其余代码不变。

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

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

③ 优缺点

优点：

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

缺点：

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

④ 扩展

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

public class SimpleCoffeeFactory {

    public static Coffee createCoffee(String type) {
        Coffee coffee = null;
        if ("american".equals(type)) {
            coffee = new AmericanCoffee();
        } else if ("latte".equals(type)) {
            coffee = new LatteCaffe();
        } else {
            throw new RuntimeException("对不起，没有您点的咖啡");
        }
        return coffee;
    }
}

public class CoffeeStore {
    public Coffee orderCoffee(String type) {
        // 直接调用类的静态方法创建对象
        Coffee coffee = SimpleCoffeeFactory.createCoffee(type);
        coffee.addMilk();
        coffee.addSugar();
        return coffee;
    }
}

4.2.3 工厂方法模式

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

① 结构

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

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

② 实现

代码实现

抽象工厂（只定义创建抽象产品【new对象】的方法）

public interface CoffeeFactory {
    // 创建咖啡对象的方法
    Coffee createCoffee();
}

具体工厂（生产具体产品【new对象】）

public class AmericanCoffeeFactory implements CoffeeFactory{
    @Override
    public Coffee createCoffee() {
        return new AmericanCoffee();
    }
}

public class LatteCoffeeFactory implements CoffeeFactory{
    @Override
    public Coffee createCoffee() {
        return new LatteCaffe();
    }
}

抽象产品和具体产品不变
咖啡店类（业务逻辑端）

public class CoffeeStore {
		// 多态性
    private CoffeeFactory factory;

    public void setFactory(CoffeeFactory factory) {
        this.factory = factory;
    }

    public Coffee orderCoffee() {
        Coffee coffee = factory.createCoffee();
        coffee.addMilk();
        coffee.addSugar();
        return coffee;
    }
}

测试类

public class test {
    public static void main(String[] args) {
        // 创建咖啡店
        CoffeeStore store = new CoffeeStore();
        // 创建工厂对象
        CoffeeFactory factory = new AmericanCoffeeFactory();
        store.setFactory(factory);
        // 点咖啡
        Coffee coffee = store.orderCoffee();
        System.out.println(coffee.getName());
    }
}

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

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

③ 优缺点

优点：

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

缺点：

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

4.2.4 抽象工厂模式

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

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

① 结构

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

② 实现

现咖啡店业务发生改变，不仅要生产咖啡还要生产甜点，如提拉米苏、抹茶慕斯等，要是按照工厂方法模式，需要定义提拉米苏类、抹茶慕斯类、提拉米苏工厂、抹茶慕斯工厂、甜点工厂类，很容易发生类爆炸情况。

其中拿铁咖啡、美式咖啡是一个产品等级，都是咖啡；提拉米苏、抹茶慕斯也是一个产品等级；拿铁咖啡和提拉米苏是同一产品族（也就是都属于意大利风味），美式咖啡和抹茶慕斯是同一产品族（也就是都属于美式风味）。所以这个案例可以使用抽象工厂模式实现。类图如下：

代码实现

抽象工厂

public interface DessertFactory {
    // 生产咖啡
    Coffee createCoffee();

    // 生产甜品
    Dessert createDessert();
}

具体工厂

public class AmericanDessertFactory implements DessertFactory{
    @Override
    public Coffee createCoffee() {
        return new AmericanCoffee();
    }

    @Override
    public Dessert createDessert() {
        return new Mousse();
    }
}

public class ItalyDessertFactory implements DessertFactory{

    @Override
    public Coffee createCoffee() {
        return new LatteCaffe();
    }

    @Override
    public Dessert createDessert() {
        return new Tiramisu();
    }
}

抽象产品和具体产品代码略
测试类

public class Test {
    public static void main(String[] args) {
        ItalyDessertFactory factory = new ItalyDessertFactory();
        Coffee coffee = factory.createCoffee();
        Dessert dessert = factory.createDessert();
        System.out.println(coffee.getName());
        dessert.show();
    }
}

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

③ 优缺点

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

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

使用场景

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

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

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

4.2.5 模式扩展

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

可以通过工厂模式+配置文件的方式解除工厂对象和产品对象的耦合。在工厂类中加载配置文件中的全类名，并创建对象进行存储，客户端如果需要对象，直接进行获取即可。

定义配置文件：新建配置文件bean.properties

1 2	american=com.hongyi.pattern.factory.factory_config.AmericanCoffee latte=com.hongyi.pattern.factory.factory_config.LatteCaffe

改进工厂类

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();
        }
    }

    /**
     * 根据名称获取对象
     * @param name 名称
     * @return Coffee
     */
    public static Coffee createCoffee(String name) {
        return map.get(name);
    }
}

public class Test {
    public static void main(String[] args) {
        Coffee coffee = CoffeeFactory.createCoffee("american");
        System.out.println(coffee.getName());
    }
}

静态成员变量map用来存储创建的对象（键存储的是名称，值存储的是对应的对象），而读取配置文件以及创建对象写在静态代码块中，目的就是只需要执行一次。

4.2.6 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()方法创建具体的商品类的对象。

关键源码

Collection抽象工厂（定义生产抽象产品的方法）

public interface Collection<E> extends Iterable<E> {
    // 生产Iterator的方法
    Iterator<E> iterator();
}

ArrayList具体工厂（实现抽象工厂的方法，并new对象【生产具体产品】）
- 具体产品Itr作为ArrayList的内部类，作为Iterator抽象类的实现类

public class ArrayList<E> extends AbstractList<E> {
    // 生产具体产品iterator
    public Iterator<E> iterator() {
        return new Itr();
    }
    // 具体产品类
    private class Itr implements Iterator<E> { 
    	// code...
    }
}

抽象产品类Iterator，代码略

4.3 原型模式

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

4.3.1 结构

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

4.3.2 实现

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

浅克隆：创建一个新对象，新对象的属性和原来对象完全相同，对于非基本类型属性，仍指向原有属性所指向的对象的内存地址。
深克隆：创建一个新对象，属性中引用的其他对象也会被克隆，不再指向原有对象地址。

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

Cloneable 接口是上面的类图中的抽象原型类，而实现了Cloneable接口的子实现类就是具体的原型类，属于深克隆。代码如下：

// 具体原型类
public class Realizetype implements Cloneable{

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

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

public class Test {
    public static void main(String[] args) throws CloneNotSupportedException {
        // 创建一个原型类对象
        Realizetype realizetype = new Realizetype();
        // 调用clone方法
        Realizetype clone = realizetype.clone();
        System.out.println(clone == realizetype); // false
    }
}

4.3.3 案例

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

实现

public class Citation implements Cloneable{

    private String name;

    public String getName() {
        return name;
    }

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

    @Override
    public Citation clone() {
        try {
            return (Citation) super.clone();
        } catch (CloneNotSupportedException e) {
            throw new AssertionError();
        }
    }

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

public class CitationTest {
    public static void main(String[] args) {
        // 创建原型对象
        Citation citation = new Citation();
        // 克隆
        Citation c1 = citation.clone();
        c1.setName("张三");
        c1.show();

        Citation c2 = citation.clone();
        c2.setName("李四");
        c2.show();
    }
}

打印结果：

1 2	张三同学：在2022学年第一学期中表现优秀，被评为三好学生。特发此状！李四同学：在2022学年第一学期中表现优秀，被评为三好学生。特发此状！

4.3.4 使用场景

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

4.4 建造者模式

4.4.1 简介

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

分离了部件的构造(由Builder来负责)和装配(由Director负责)。从而可以构造出复杂的对象。这个模式适用于：某个对象的构建过程复杂的情况。
由于实现了构建和装配的解耦。不同的构建器，相同的装配，也可以做出不同的对象；相同的构建器，不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦，实现了更好的复用。
建造者模式可以将部件和其组装过程分开，一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象，而无须知道其内部的具体构造细节。

4.4.2 结构

抽象建造者类（Builder）：这个接口规定要实现复杂对象的那些部分的创建，并不涉及具体的部件对象的创建。
具体建造者类（Concrete Builder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。在构造过程完成后，提供产品的实例。
产品类（Product）：要创建的复杂对象。
指挥者类（Director）：调用具体建造者来创建复杂对象的各个部分，在指导者中不涉及具体产品的信息，只负责保证对象各部分完整创建或按某种顺序创建。

4.4.3 案例

创建共享单车

生产自行车是一个复杂的过程，它包含了车架，车座等组件的生产。而车架又有碳纤维，铝合金等材质的，车座有橡胶，真皮等材质。对于自行车的生产就可以使用建造者模式。

这里Bike是产品类，包含车架，车座等组件；Builder是抽象建造者，MobikeBuilder和OfoBuilder是具体的建造者；Director是指挥者。类图如下：

代码

抽象建造者类

public abstract class Builder {
    // 声明一个Bike类型的变量，并赋值，但是并未构建
    protected Bike bike = new Bike();

    // 声明抽象建造方法，由具体建造者实现
    public abstract void buildFrame();

    public abstract  void buildSeat();

    public abstract Bike createBike();
}

具体建造者类

public class OfoBuilder extends Builder{
    @Override
    public void buildFrame() {
        bike.setFrame("Ofo车架");
    }

    @Override
    public void buildSeat() {
        bike.setSeat("Ofo车座");
    }

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

public class MobikeBuilder extends Builder{
    @Override
    public void buildFrame() {
        bike.setFrame("摩拜车架");
    }

    @Override
    public void buildSeat() {
        bike.setSeat("摩拜车座");
    }

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

产品类

@Data
public class Bike {
    // 车架
    private String frame;
    // 车座
    private String seat;
}

指挥者类

public class Director {

    private Builder builder;

    public Director(Builder builder) {
        this.builder = builder;
    }

    // 组装自行车
    public Bike construct() {
        builder.buildFrame();
        builder.buildSeat();
        return builder.createBike();
    }
}

测试类

public class Test {
    public static void main(String[] args) {
        // 创建指挥者
        Director director = new Director(new MobikeBuilder());
        // 指挥组装
        Bike bike = director.construct();
        System.out.println(bike.getFrame());
        System.out.println(bike.getSeat());
    }
}

4.4.4 优缺点

优点：

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

缺点：

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

4.4.5 使用场景

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

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

4.4.6 模式扩展

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

重构前代码

@Data
@AllArgsConstructor
@ToString
public class Phone {
    private String cpu;
    private String screen;
    private String memory;
    private String mainboard;
}

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

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

重构后代码

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

    // 私有构造方法
    private Phone(Builder builder) {
        this.cpu = builder.cpu;
        this.screen = builder.screen;
        this.memory = builder.memory;
        this.mainboard = builder.mainboard;
    };

    // 静态内部类——建造者类
    public static final class Builder {
        private String cpu;
        private String screen;
        private String memory;
        private String mainboard;

        public Builder cpu(String cpu) {
            this.cpu = cpu;
            return this;
        }

        public Builder screen(String screen) {
            this.screen = screen;
            return this;
        }

        public Builder memory(String memory) {
            this.memory = memory;
            return this;
        }

        public Builder mainboard(String mainboard) {
            this.mainboard = mainboard;
            return this;
        }

        // 使用构建者创建对象
        public Phone build() {
            return new Phone(this);
        }
    }
}

public class Test {
    public static void main(String[] args) {
        // 使用构建者创建对象
        Phone phone = new Phone.Builder()
                .cpu("intel") // 链式调用
                .screen("三星")
                .memory("金士顿")
                .mainboard("华硕")
                .build();
        System.out.println(phone);
    }
}

4.5 创建者模式对比

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

工厂方法模式注重的是整体对象的创建方式；而建造者模式注重的是部件构建的过程，意在通过一步一步地精确构造创建出一个复杂的对象。

我们举个简单例子来说明两者的差异，如要制造一个超人，如果使用工厂方法模式，直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人；而如果使用建造者模式，则需要组装手、头、脚、躯干等部分，然后再把内裤外穿，于是一个超人就诞生了。

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

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

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

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

5 结构型模式

结构型模式描述如何将类或对象按某种布局组成更大的结构。它分为类结构型模式和对象结构型模式，前者采用继承机制来组织接口和类，后者釆用组合或聚合来组合对象。

由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象结构型模式比类结构型模式具有更大的灵活性。

结构型模式分为以下 7 种：

代理模式
适配器模式
装饰者模式
桥接模式
外观模式
组合模式
享元模式

5.1 代理模式

5.1.1 简介

由于某些原因需要给某对象提供一个代理以控制对该对象的访问。这时，访问对象不适合或者不能直接引用目标对象，代理对象作为访问对象和目标对象之间的中介。

Java中的代理按照代理类生成时机不同又分为静态代理和动态代理。

静态代理代理类在编译期就生成，而动态代理代理类则是在Java运行时动态生成（内存中生成）。动态代理又有JDK代理和CGLib代理两种。

5.1.2 结构

代理（Proxy）模式分为三种角色：

抽象主题（Subject）类：通过接口或抽象类声明真实主题和代理对象实现的业务方法。
真实主题（Real Subject）类：实现了抽象主题中的具体业务，是代理对象所代表的真实对象，是最终要引用的对象（目标对象）。
代理（Proxy）类：提供了与真实主题相同的接口，其内部含有对真实主题的引用，它可以访问、控制或扩展真实主题的功能。

角色：目标对象和代理对象（含有目标对象的引用）

5.1.3 静态代理

案例：火车站卖票

如果要买火车票的话，需要去火车站买票，坐车到火车站，排队等一系列的操作，显然比较麻烦。而火车站在多个地方都有代售点，我们去代售点买票就方便很多了。这个例子其实就是典型的代理模式，火车站是目标对象，代售点是代理对象。类图如下：

代码实现

抽象主题类——接口

// 卖火车票的接口——抽象主题类
public interface SellTickets {
  void sell();
}

真实主题类——实现接口

// 火车站类——具体主题类
public class TrainStation implements SellTickets{
  @Override
  public void sell() {
    System.out.println("火车站买票");
  }
}

代理类——同样也实现接口，对sell进行增强

// 代售点——代理类
public class ProxyPoint implements SellTickets{ // 实现与真实主题相同的接口
  // 对真实主题的引用
  private TrainStation trainStation = new TrainStation();
  // 方法增强
  @Override
  public void sell() {
    System.out.println("代理点收取额外费用");
    trainStation.sell();
  }
}

测试类

public class Test {
  public static void main(String[] args) {
    // 创建代理类对象
    ProxyPoint proxyPoint = new ProxyPoint();
    // 买票
    proxyPoint.sell();
  }
}

从上面代码中可以看出测试类直接访问的是ProxyPoint类对象，也就是说ProxyPoint作为访问对象和目标对象的中介。同时也对sell方法进行了增强（代理点收取一些服务费用）。

5.1.4 JDK动态代理

① 实现

我们使用动态代理实现上面案例，先说说JDK提供的动态代理。Java中提供了一个动态代理类Proxy，Proxy并不是我们上述所说的代理对象的类，而是提供了一个创建代理类的对象的静态方法（newProxyInstance方法）来获取代理对象。

获取代理对象的工厂类

// 获取代理对象的工厂类
public class ProxyFactory {

  // 声明目标对象
  private TrainStation station = new TrainStation();

  // 获取代理对象
  public SellTickets getProxyObject() {
    /*
     * ClassLoader loader ： 类加载器，用于加载代理类。可以通过目标对象获取类加载器
     * Class<?>[] interfaces ： 代理类实现的接口的字节码对象
     * InvocationHandler h ： 代理对象的调用处理程序
     */
    return (SellTickets) Proxy.newProxyInstance(
      station.getClass().getClassLoader(),
      station.getClass().getInterfaces(),
      /*
      * proxy 代理对象，基本不用
      * method 对接口(SellTickets)中的方法(sell)进行封装的对象
      * args 调用方法(sell)的实际参数
      * 返回值：方法(sell)的返回值
      */
      // 此处是InvocationHandler的子实现匿名内部类，采用了lambda表达式
      (proxy, method, args) -> {
        // System.out.println("invoke方法执行...");
        // 方法增强
        System.out.println("代售点收取额外费用...");
        // 执行目标对象的方法
        return method.invoke(station, args);
      }
    );
  }
}

测试类

public class Test {
  public static void main(String[] args) {
    // 获取代理对象
    // 1.创建代理工厂对象
    ProxyFactory factory = new ProxyFactory();
    // 2.使用工厂对象获取代理对象
    SellTickets proxyObject = factory.getProxyObject();
    // 3.调用方法
    proxyObject.sell();
  }
}

② 原理

问题：ProxyFactory是代理类吗？

ProxyFactory不是代理模式中所说的代理类，而代理类是程序在运行过程中动态的在内存中生成的类。通过阿里巴巴开源的 Java 诊断工具（Arthas【阿尔萨斯】）查看代理类的结构：

// 动态在内存中生成的代理类，实现了抽象主题类（被代理类）的接口
// 父类是Proxy
public final class $Proxy0 extends Proxy implements SellTickets { 
    private static Method m3; 
    // 构造方法
    public $Proxy0(InvocationHandler invocationHandler) {
        // 调用父类的构造方法（下面代码的第5,6,7行处）
        super(invocationHandler); 
    }
    static {
        m3 = Class.forName("com.itheima.proxy.dynamic.jdk.SellTickets").getMethod("sell", new Class[0]); 
    }
    public final void sell() {
        this.h.invoke(this, m3, null);
    }
}

从上面的类中，我们可以看到以下几个信息：

代理类（$Proxy0）实现了SellTickets接口。这也就印证了我们之前说的真实类和代理类实现同样的接口。
代理类（$Proxy0）将我们提供的匿名内部类对象传递给了父类。

//Java提供的动态代理相关类 
public class Proxy implements java.io.Serializable { 
  protected InvocationHandler h; 
  // 构造方法，该方法由子类调用，完成子类对象的构造（上面代码的第6行处）
  protected Proxy(InvocationHandler h) { 
    this.h = h; 
  }
}

③ 执行流程

在测试类中通过代理对象调用sell()方法
1
proxyObject.sell();

根据多态的特性，执行的是代理类（$Proxy0）中的sell()方法

1 2	SellTickets proxyObject = factory.getProxyObject(); // 多态，编译看左边，执行看右边 proxyObject.sell();

代理类（$Proxy0）中的sell()方法中又调用了InvocationHandler接口的子实现类对象的invoke方法，即代码中的lambda表达式
invoke方法通过反射执行了真实对象所属类(TrainStation)中的sell()方法

5.1.5 CGLIB动态代理

如果没有定义SellTickets接口，只定义了TrainStation(火车站类)。很显然JDK代理是无法使用了，因为JDK动态代理要求必须定义接口，对接口进行代理。

CGLIB是一个功能强大，高性能的代码生成包。它为没有实现接口的类提供代理，为JDK的动态代理提供了很好的补充。

CGLIB是第三方提供的包，所以需要引入jar包的坐标：

<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>2.2.2</version>
</dependency>

代码实现

真实类

public class TrainStation {
  public void sell() {
    System.out.println("火车站买票");
  }
}

注意没有接口实现了

代理对象工厂类

public class ProxyFactory implements MethodInterceptor {

  // 声明目标对象（代理类的父类）
  private TrainStation station = new TrainStation();

  public TrainStation getProxyObject() {
    // 创建Enhancer对象，类似于JDK代理中的Proxy类
    Enhancer enhancer = new Enhancer();
    // 设置父类的字节码对象（指定代理类的父类）
    enhancer.setSuperclass(TrainStation.class);
    // 设置回调函数
    enhancer.setCallback(this);
    // 创建代理对象
    TrainStation proxyObject = (TrainStation) enhancer.create();
    return proxyObject;
  }

  @Override
  public Object intercept(Object o, Method method, Object[] objects, MethodProxy methodProxy) throws Throwable {
    System.out.println("代售点收取额外费用");
    // 调用目标对象的方法
    method.invoke(station, objects);
    return null;
  }
}

测试类

public class Test {
  public static void main(String[] args) {
    // 创建代理工厂对象
    ProxyFactory factory = new ProxyFactory();
    // 获取代理对象
    TrainStation proxyObject = factory.getProxyObject();
    // 调用代理对象中的sell方法
    proxyObject.sell();
  }
}

5.1.6 三种代理对比

jdk代理和CGLIB代理
- 使用CGLib实现动态代理，CGLib底层采用ASM字节码生成框架，使用字节码技术生成代理类，在JDK1.6之前比使用Java反射效率要高。唯一需要注意的是，CGLib不能对声明为final的类或者方法进行代理，因为CGLib原理是动态生成被代理类的子类。
- 在JDK1.6、JDK1.7、JDK1.8逐步对JDK动态代理优化之后，在调用次数较少的情况下，JDK代理效率高于CGLib代理效率，只有当进行大量调用的时候，JDK1.6和JDK1.7比CGLib代理效率低一点，但是到JDK1.8的时候，JDK代理效率高于CGLib代理。所以如果有接口使用JDK动态代理，如果没有接口使用CGLIB代理。
动态代理和静态代理
- 动态代理与静态代理相比较，最大的好处是接口中声明的所有方法都被转移到调用处理器一个集中的方法中处理（InvocationHandler.invoke）。这样，在接口方法数量比较多的时候，我们可以进行灵活处理，而不需要像静态代理那样每一个方法进行中转。
- 如果接口增加一个方法，静态代理模式除了所有实现类需要实现这个方法外，所有代理类也需要实现此方法。增加了代码维护的复杂度。而动态代理不会出现该问题。

5.1.7 优缺点

优点：

代理模式在客户端与目标对象之间起到一个中介作用和保护目标对象的作用；
代理对象可以扩展目标对象的功能；
代理模式能将客户端与目标对象分离，在一定程度上降低了系统的耦合度；

缺点：

增加了系统的复杂度；

5.1.8 使用场景

远程（Remote）代理：本地服务通过网络请求远程服务。为了实现本地到远程的通信，我们需要实现网络通信，处理其中可能的异常。为良好的代码设计和可维护性，我们将网络通信部分隐藏起来，只暴露给本地服务一个接口，通过该接口即可访问远程服务提供的功能，而不必过多关心通信部分的细节。
防火墙（Firewall）代理：当你将浏览器配置成使用代理功能时，防火墙就将你的浏览器的请求转给互联网；当互联网返回响应时，代理服务器再把它转给你的浏览器。
保护（Protect or Access）代理：控制对一个对象的访问，如果需要，可以给不同的用户提供不同级别的使用权限。

5.2 适配器模式

5.2.1 简介

定义：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。

适配器模式分为类适配器模式和对象适配器模式，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

5.2.2 结构

适配器模式（Adapter）包含以下主要角色：

目标（Target）接口：当前系统业务所期待的接口，它可以是抽象类或接口。
适配者（Adaptee）类：它是被访问和适配的现存组件库中的组件接口。
适配器（Adapter）类：它是一个转换器，通过继承或引用适配者的对象，把适配者接口转换成目标接口，让客户按目标接口的格式访问适配者。

5.2.3 类适配模式

实现方式：定义一个适配器类来实现当前系统的业务接口（目标接口），同时又继承现有组件库中已经存在的组件（适配者类）。

即：适配器类需要实现目标接口，继承适配者类

【例】读卡器

现有一台电脑只能读取SD卡，而要读取TF卡中的内容的话就需要使用到适配器模式。创建一个读卡器，将TF卡中的内容读取出来。

目标接口：SDCard
适配者类：TFCard
适配器类：SDAdapterTF

代码实现

SDCard接口及其实现类【目标接口】（TFCard略【适配者类】）

public interface SDCard {
    // 从SD卡中读取数据
    String readSD();

    // 向SD卡中写入数据
    void writeSD(String data);
}

public class SDCardImpl implements SDCard{
    @Override
    public String readSD() {
        // 模拟读取数据
        return "SDCard read data : hello SDCard";
    }

    @Override
    public void writeSD(String data) {
        System.out.println("SDCard write data: " + data);
    }
}

Computer类（只能适配SDCard）

public class Computer {
    // 从SD读取数据
    public String readSD(SDCard sdCard) {
        if (sdCard == null) {
            throw new NullPointerException("sd card is null");
        }
        return sdCard.readSD();
    }
}

适配器类

// 实现目标接口，继承适配者类
public class SDAdapterTF extends TFCardImpl implements SDCard{

    @Override
    public String readSD() {
        System.out.println("adapter read tf card");
        // 返回的实际上是从tf中读取的数据
        return readTF();
    }

    @Override
    public void writeSD(String data) {
        System.out.println("adapter write tf card");
        writeTF(data);
    }
}

测试类

public class Test {
    public static void main(String[] args) {
        // 创建计算机对象
        Computer computer = new Computer();
        // 读取sd数据
        String data = computer.readSD(new SDCardImpl());
        System.out.println(data);

        System.out.println("===================");
        // 使用该计算机读取TF卡中的数据
        // 定义适配器类:因为SDAdapterTF实现了SDCard接口，因此可以传入computer.readSD()方法中
        SDAdapterTF sdAdapterTF = new SDAdapterTF();
        // 读取tf数据
        String data1 = computer.readSD(sdAdapterTF);
        System.out.println(data1);
    }
}

SDCard read data : hello SDCard
===================
adapter read tf card
TFCard read data : hello TFCard

类适配器模式违背了合成复用原则。类适配器是客户类有一个接口规范（例如只适配TF）的情况下可用，反之不可用（不能够多继承）。

5.2.4 对象适配模式

实现方式：对象适配器模式可釆用将现有组件库中已经实现的组件引入适配器类中，该类同时实现当前系统的业务接口。

即适配器类需要引入适配者类，实现目标接口。

使用对象适配器模式将读卡器的案例进行改写。类图如下：

代码实现

只需要修改适配器类（SDAdapterTF）和测试类。

适配器类

// 适配器类
public class SDAdapterTF implements SDCard {

    // 引入适配者类
    private TFCard tfCard;

    public SDAdapterTF(TFCard tfCard) {
        this.tfCard = tfCard;
    }

    @Override
    public String readSD() {
        System.out.println("adapter read tf card");
        return tfCard.readTF();
    }

    @Override
    public void writeSD(String data) {
        System.out.println("adapter write tf card");
        tfCard.writeTF(data);
    }
}

测试类

public class Test {
    public static void main(String[] args) {
        // 创建计算机对象
        Computer computer = new Computer();
        String data = computer.readSD(new SDCardImpl());
        System.out.println(data);

        System.out.println("===================");
        // 使用该计算机读取TF卡中的数据
        String data1 = computer.readSD(new SDAdapterTF(new TFCardImpl()));
        System.out.println(data1);
    }
}

5.2.5 使用场景

以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同。

5.2.6 源码解析

Reader（字符流）、InputStream（字节流）的适配使用的是InputStreamReader【适配器】。

InputStreamReader继承自java.io包中的Reader，对他【Reader】中的抽象的未实现的方法给出实现，例如：

public int read() throws IOException { 
    return sd.read(); 
}
public int read(char cbuf[], int offset, int length) throws IOException { 
    return sd.read(cbuf, offset, length); 
}

如上代码中的sd（StreamDecoder类对象【解码：字节—->字符】），在Sun的JDK实现中，实际的方法实现是对sun.nio.cs.StreamDecoder类的同名方法的调用封装。

类结构图如下：

从表层来看，InputStreamReader做了InputStream字节流类到Reader字符流之间的转换。而从如上Sun JDK中的实现类关系结构中可以看出，是StreamDecoder的设计实现在实际上采用了适配器模式。

5.3 装饰者模式

5.3.1 简介

在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式。

5.3.2 结构

装饰（Decorator）模式中的角色：

抽象构件（Component）角色 ：定义一个抽象接口以规范准备接收附加责任的对象。
具体构件（Concrete Component）角色 ：实现抽象构件，通过装饰角色为其添加一些职责。
抽象装饰（Decorator）角色 ：继承或实现抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
具体装饰（ConcreteDecorator）角色 ：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

5.3.3 实现

案例：【快餐店】

快餐店有炒面、炒饭这些快餐，可以额外附加鸡蛋、火腿、培根这些配菜，当然加配菜需要额外加钱，每个配菜的价钱通常不太一样，那么计算总价就会显得比较麻烦。

代码实现

抽象构件

@Data
@AllArgsConstructor
@NoArgsConstructor
public abstract class Fastfood {
    private float price;
    private String desc;
    public abstract float cost();
}

具体构件

public class FriedRice extends Fastfood{

    public FriedRice() {
        // 调用父类构造器
        super(10, "炒饭");
    }

    @Override
    public float cost() {
        // 调用父类方法
        return getPrice();
    }
}

public class FriedNoodles extends Fastfood{

    public FriedNoodles() {
        // 调用父类构造器
        super(12, "炒面");
    }

    @Override
    public float cost() {
        // 调用父类方法
        return getPrice();
    }
}

抽象装饰

@Data
public abstract class Garnish extends Fastfood{
    // 声明抽象构件
    private Fastfood fastfood;

    public Garnish(Fastfood fastfood, float price, String desc) {
        super(price, desc);
        this.fastfood = fastfood;
    }
}

具体装饰

public class Eggs extends Garnish{

    public Eggs(Fastfood fastfood) {
        super(fastfood, 1, "鸡蛋");
    }

    @Override
    public float cost() {
        // 计算价格
        return getPrice() + getFastfood().cost();
    }

    @Override
    public String getDesc() {
        return super.getDesc() + getFastfood().getDesc();
    }
}

public class Bacon extends Garnish{

    public Bacon(Fastfood fastfood) {
        super(fastfood, 2, "培根");
    }

    @Override
    public float cost() {
        // 计算价格
        return getPrice() + getFastfood().cost();
    }

    @Override
    public String getDesc() {
        return super.getDesc() + getFastfood().getDesc();
    }
}

测试类

public class Test {
    public static void main(String[] args) {
        // 点一份炒饭
        Fastfood food = new FriedRice();
        System.out.println(food.getDesc() + "  " + food.cost() + "元");
        System.out.println("============");
        // 在炒饭中加一个鸡蛋
        food = new Eggs(food);
        System.out.println(food.getDesc() + "  " + food.cost() + "元");
        System.out.println("============");
        // 再加一份培根
        food = new Bacon(food);
        System.out.println(food.getDesc() + "  " + food.cost() + "元");
    }
}

炒饭  10.0元
============
鸡蛋炒饭  11.0元
培根鸡蛋炒饭  13.0元

装饰者模式可以带来比继承更加灵活性的扩展功能，使用更加方便，可以通过组合不同的装饰者对象来获取具有不同行为状态的多样化的结果。装饰者模式比继承更具良好的扩展性，完美的遵循开闭原则，继承是静态的附加责任，装饰者则是动态的附加责任。
装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。

5.3.4 使用场景

当不能采用继承的方式对系统进行扩充或者采用继承不利于系统扩展和维护时。不能采用继承的情况主要有两类：
- 第一类是系统中存在大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长；
- 第二类是因为类定义不能继承（如final类）
在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。
当对象的功能要求可以动态地添加，也可以再动态地撤销时。

5.3.5 源码解析

略

5.4 桥接模式

5.4.1 概述

现在有一个需求，需要创建不同的图形，并且每个图形都有可能会有不同的颜色。我们可以利用继承的方式来设计类的关系：

我们可以发现有很多的类，假如我们再增加一个形状或再增加一种颜色，就需要创建更多的类。

试想，在一个有多种可能会变化的维度的系统中，用继承方式会造成类爆炸，扩展起来不灵活。每次在一个维度上新增一个具体实现都要增加多个子类。为了更加灵活的设计系统，我们此时可以考虑使用桥接模式。

桥接模式定义：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

5.4.2 结构

桥接（Bridge）模式包含以下主要角色：

抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用。
扩展抽象化（Refined Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。
实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用。
具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。

5.4.3 实现

【例】视频播放器

需要开发一个跨平台视频播放器，可以在不同操作系统平台（如Windows、Mac、Linux等）上播放多种格式的视频文件，常见的视频格式包括RMVB、AVI、WMV等。该播放器包含了两个维度，适合使用桥接模式。

类图如下：

实现代码

实现化角色

public interface VideoFile {
    // 解码功能
    void decode(String fileName);
}

具体实现化角色

public class AVIFile implements VideoFile{
    @Override
    public void decode(String fileName) {
        System.out.println("AVI视频文件：" + fileName);
    }
}

抽象化角色

public abstract class OperatingSystem {
    // 声明VideoFile对象，即包含对实现化对象的引用
    // 利用 组合 方式代替继承方式
    protected VideoFile videoFile;

    // 显式声明构造方法，要求实现子类必须实现
    public OperatingSystem(VideoFile videoFile) {
        this.videoFile = videoFile;
    }

    public abstract void play(String fileName);
}

扩展抽象化角色

public class Windows extends OperatingSystem{

    public Windows(VideoFile videoFile) {
        super(videoFile);
    }

    @Override
    public void play(String fileName) {
        videoFile.decode(fileName);
    }

}

测试

public class Test {
    public static void main(String[] args) {
        // 创建Mac系统
        OperatingSystem system = new Mac(new AVIFile());
        // 使用操作系统播放视频文件
        system.play("泰坦尼克号"); // AVI视频文件：泰坦尼克号
    }
}

桥接模式提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统。

如：如果现在还有一种视频文件类型wmv，我们只需要再定义一个类实现VideoFile接口即可，其他类不需要发生变化。

实现细节对客户透明

5.4.4 使用场景

当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时。
当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。避免在两个层次之间建立静态的继承联系，通过桥接模式可以使它们在抽象层建立一个关联关系。

5.5 外观模式

5.5.1 概述

有些人可能炒过股票，但其实大部分人都不太懂，这种没有足够了解证券知识的情况下做股票是很容易亏钱的，刚开始炒股肯定都会想，如果有个懂行的帮帮手就好，其实基金就是个好帮手，支付宝里就有许多的基金，它将投资者分散的资金集中起来，交由专业的经理人进行管理，投资于股票、债券、外汇等领域，而基金投资的收益归持有者所有，管理机构收取一定比例的托管管理费用。

外观模式定义：又名门面模式，是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

外观（Facade[fəˈsɑːd]）模式是“迪米特法则”的典型应用。

5.5.2 结构

外观（Facade）角色：为多个子系统对外提供一个共同的接口。
子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。

5.5.3 实现

【例】智能家电控制

小明的爷爷已经60岁了，一个人在家生活：每次都需要打开灯、打开电视、打开空调；睡觉时关闭灯、关闭电视、关闭空调；操作起来都比较麻烦。所以小明给爷爷买了智能音箱，可以通过语音直接控制这些智能家电的开启和关闭。类图如下：

代码实现

子系统角色

public class Light {
    public void on() {
        System.out.println("打开电灯");
    }

    public void off() {
        System.out.println("关闭电灯");
    }
}

public class TV {
    public void on() {
        System.out.println("打开TV");
    }

    public void off() {
        System.out.println("关闭TV");
    }
}

外观角色

public class SmartAppliancesFacade {
    // 聚合电灯、电视机、空调对象
    private Light light;
    private TV tv;
    private AirCondition airCondition;

    public SmartAppliancesFacade() {
        light = new Light();
        tv = new TV();
        airCondition = new AirCondition();
    }

    // 通过语音控制
    public void say(String msg) {
        if (msg.contains("打开")) {
            on();
        } else if(msg.contains("关闭")) {
            off();
        } else {
            System.out.println("IDK");
        }
    }

    // 一键打开功能
    private void on() {
        light.on();
        tv.on();
        airCondition.on();
    }

    // 一键关闭功能
    private void off() {
        light.off();
        tv.off();
        airCondition.off();
    }
}

降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
缺点：不符合开闭原则，修改很麻烦

5.5.4 使用场景

对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。

5.5.5 源码解析

使用tomcat作为web容器时，接收浏览器发送过来的请求，tomcat会将请求信息封装成ServletRequest对象，如下图①处对象。但是ServletRequest是一个接口，它还有一个子接口HttpServletRequest，而我们知道该request对象肯定是一个HttpServletRequest对象的子实现类对象，到底是哪个类的对象呢？可以通过输出request对象，我们就会发现是一个名为RequestFacade的类的对象。

RequestFacade类就使用了外观模式。先看结构图：

定义 RequestFacade 类（外观对象），分别实现 ServletRequest ，同时定义私有成员变量 Request（子系统对象），并且方法的实现调用 Request 的实现。然后，将 RequestFacade上转为 ServletRequest 传给servlet 的 service 方法，这样即使在 servlet 中被下转为 RequestFacade ，也不能访问私有成员变量对象中的方法。既用了 Request ，又能防止其中方法被不合理的访问。

5.6 组合模式

5.6.1 概述

对于这个图片肯定会非常熟悉，上图我们可以看做是一个文件系统，对于这样的结构我们称之为树形结构。在树形结构中可以通过调用某个方法来遍历整个树，当我们找到某个叶子节点后，就可以对叶子节点进行相关的操作。可以将这颗树理解成一个大的容器，容器里面包含很多的成员对象，这些成员对象即可是容器对象也可以是叶子对象。但是由于容器对象和叶子对象在功能上面的区别，使得我们在使用的过程中必须要区分容器对象和叶子对象，但是这样就会给客户带来不必要的麻烦，作为客户而已，它始终希望能够一致的对待容器对象和叶子对象。

组合模式定义：又名部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。

5.6.2 结构

抽象根节点（Component）：定义系统各层次对象的共有方法和属性，可以预先定义一些默认行为和属性。
树枝节点（Composite）：定义树枝节点的行为，存储子节点，组合树枝节点和叶子节点形成一个树形结构。
叶子节点（Leaf）：叶子节点对象，其下再无分支，是系统层次遍历的最小单位。

5.6.3 实现

【例】软件菜单

如下图，我们在访问别的一些管理系统时，经常可以看到类似的菜单。一个菜单可以包含菜单项（菜单项是指不再包含其他内容的菜单条目），也可以包含带有其他菜单项的菜单，因此使用组合模式描述菜单就很恰当，我们的需求是针对一个菜单，打印出其包含的所有菜单以及菜单项的名称。

代码实现

抽象根节点

// 抽象根节点
public abstract class MenuComponent {
    // 菜单组件的名称
    protected String name;
    // 菜单组件的层级
    protected int level;

    // 添加子菜单
    public void add(MenuComponent menuComponent) {
        throw new UnsupportedOperationException();
    }

    // 移除子菜单
    public void remove(MenuComponent menuComponent) {
        throw new UnsupportedOperationException();
    }

    // 获取指定的子菜单
    public MenuComponent getChild(int index) {
        throw new UnsupportedOperationException();
    }

    // 获取菜单或菜单项的名称
    public String getName() {
        return name;
    }

    // 打印菜单名称（包含子菜单和子菜单项）
    public abstract void print();
}

这里的MenuComponent定义为抽象类，因为有一些共有的属性和行为要在该类中实现，Menu和MenuItem类就可以只覆盖自己感兴趣的方法，而不用搭理不需要或者不感兴趣的方法，举例来说，Menu类可以包含子菜单，因此需要覆盖add()、remove()、getChild()方法，但是MenuItem就不应该有这些方法。这里给出的默认实现是抛出异常，你也可以根据自己的需要改写默认实现。

树枝节点

public class Menu extends MenuComponent{

    // 菜单可以有多个子菜单或子菜单项
    private List<MenuComponent> menuComponents = new ArrayList<>();

    // 构造方法
    public Menu(String name, int level) {
        this.name = name;
        this.level = level;
    }

    @Override
    public void add(MenuComponent menuComponent) {
        menuComponents.add(menuComponent);
    }

    @Override
    public void remove(MenuComponent menuComponent) {
        menuComponents.remove(menuComponent);
    }

    @Override
    public MenuComponent getChild(int index) {
        return menuComponents.get(index);
    }

    @Override
    public void print() {
        // 打印菜单名称
        for (int i  = 0;i < level; i++) {
            System.out.print("--");
        }
        System.out.println(name);
        // 打印子菜单名称或子菜单项名称
        for (MenuComponent menuComponent : menuComponents) {
            menuComponent.print();
        }
    }
}

Menu类已经实现了除了getName方法的其他所有方法，因为Menu类具有添加菜单，移除菜单和获取子菜单的功能。

叶子节点

public class MenuItem extends MenuComponent{

    public MenuItem(String name, int level) {
        this.name = name;
        this.level = level;
    }

    @Override
    public void print() {
        for (int i  = 0;i < level; i++) {
            System.out.print("--");
        }
        System.out.println(this.name);
    }
}

MenuItem是菜单项，不能再有子菜单，所以添加菜单，移除菜单和获取子菜单的功能并不能实现。

测试

public class Test {
    public static void main(String[] args) {
        // 创建菜单树
        MenuComponent menu1 = new Menu("菜单管理", 2);
        // 添加菜单项
        menu1.add(new MenuItem("页面访问", 3));
        menu1.add(new MenuItem("展开菜单", 3));
        menu1.add(new MenuItem("编辑菜单", 3));
        menu1.add(new MenuItem("删除菜单", 3));
        menu1.add(new MenuItem("新增菜单", 3));

        MenuComponent menu2 = new Menu("权限管理", 2);
        menu2.add(new MenuItem("页面访问", 3));
        menu2.add(new MenuItem("提交保存", 3));

        MenuComponent menu3 = new Menu("角色管理", 2);
        menu3.add(new MenuItem("页面访问", 3));
        menu3.add(new MenuItem("新增角色", 3));
        menu3.add(new MenuItem("修改角色", 3));

        // 创建一级菜单
        MenuComponent component = new Menu("系统管理", 1);

        // 将二级菜单添加到一级菜单中
        component.add(menu1);
        component.add(menu2);
        component.add(menu3);

        // 打印菜单名称
        component.print();
    }
}

--系统管理
----菜单管理
------页面访问
------展开菜单
------编辑菜单
------删除菜单
------新增菜单
----权限管理
------页面访问
------提交保存
----角色管理
------页面访问
------新增角色
------修改角色

5.6.4 分类

在使用组合模式时，根据抽象构件类的定义形式，我们可将组合模式分为透明组合模式和安全组合模式两种形式。

透明组合模式
- 透明组合模式中，抽象根节点角色中声明了所有用于管理成员对象的方法，比如在示例中MenuComponent 声明了 add 、 remove 、 getChild 方法，这样做的好处是确保所有的构件类都有相同的接口。透明组合模式也是组合模式的标准形式。
- 透明组合模式的缺点是不够安全，因为叶子对象和容器对象在本质上是有区别的，叶子对象不可能有下一个层次的对象，即不可能包含成员对象，因此为其提供 add()、remove() 等方法是没有意义的，这在编译阶段不会出错，但在运行阶段如果调用这些方法可能会出错（如果没有提供相应的错误处理代码）
安全组合模式
- 在安全组合模式中，在抽象构件角色中没有声明任何用于管理成员对象的方法，而是在树枝节点Menu 类中声明并实现这些方法。安全组合模式的缺点是不够透明，因为叶子构件和容器构件具有不同的方法，且容器构件中那些用于管理成员对象的方法没有在抽象构件类中定义，因此客户端不能完全针对抽象编程，必须有区别地对待叶子构件和容器构件。

5.6.5 优点和使用场景

组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，它让客户端忽略了层次的差异，方便对整个层次结构进行控制。
客户端可以一致地使用一个组合结构或其中单个对象，不必关心处理的是单个对象还是整个组合结构，简化了客户端代码。
在组合模式中增加新的树枝节点和叶子节点都很方便，无须对现有类库进行任何修改，符合“开闭原则”。
组合模式为树形结构的面向对象实现提供了一种灵活的解决方案，通过叶子节点和树枝节点的递归组合，可以形成复杂的树形结构，但对树形结构的控制却非常简单。

组合模式正是应树形结构而生，所以组合模式的使用场景就是出现树形结构的地方。比如：文件目录显示，多级目录呈现等树形结构数据的操作。

5.7 享元模式

5.7.1 概述

运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似对象的开销，从而提高系统资源的利用率。

5.7.2 结构

享元（Flyweight ）模式中存在以下两种状态：

内部状态，即不会随着环境的改变而改变的可共享部分。
外部状态，指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化。

享元模式的主要有以下角色：

抽象享元角色（Flyweight）：通常是一个接口或抽象类，在抽象享元类中声明了具体享元类公共的方法，这些方法可以向外界提供享元对象的内部数据（内部状态），同时也可以通过这些方法来设置外部数据（外部状态）。
具体享元（Concrete Flyweight）角色：它实现了抽象享元类，称为享元对象；在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类，为每一个具体享元类提供唯一的享元对象。
非享元（Unsharable Flyweight)角色：并不是所有的抽象享元类的子类都需要被共享，不能被共享的子类可设计为非共享具体享元类；当需要一个非共享具体享元类的对象时可以直接通过实例化创建。
享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。

5.7.3 实现

【例】俄罗斯方块

下面的图片是众所周知的俄罗斯方块中的一个个方块，如果在俄罗斯方块这个游戏中，每个不同的方块都是一个实例对象，这些对象就要占用很多的内存空间，下面利用享元模式进行实现。

类图：

代码实现

俄罗斯方块有不同的形状，我们可以对这些形状向上抽取出AbstractBox，用来定义共性的属性和行为。

抽象享元

// 抽象享元角色
public abstract class AbstractBox {
    // 获取图形
    public abstract String getShape();

    // 显示图形和颜色,具体享元的公共方法
    public void display(String color) {
        System.out.println("形状：" + getShape() + ", 颜色：" + color);
    }
}

具体享元

// 具体享元角色
public class IBox extends AbstractBox{
    @Override
    public String getShape() {
        return "I";
    }
}

享元工厂

// 工厂类，设计为单例
public class BoxFactory {
    private HashMap<String , AbstractBox> map;

    private static final BoxFactory factory = new BoxFactory();

    // 私有构造方法
    private BoxFactory() {
        map = new HashMap<String , AbstractBox>();
        map.put("I", new IBox());
        map.put("L", new LBox());
        map.put("O", new OBox());
    }

    // 提供方法获取该工厂类对象
    public static BoxFactory getInstance() {
        return factory;
    }

    // 根据名称获取图形对象
    public AbstractBox getShape(String name) {
        return map.get(name);
    }

}

测试

public class Test {
    public static void main(String[] args) {
        // 获取I图形
        AbstractBox box1 = BoxFactory.getInstance().getShape("I");
        box1.display("Black");

        // 获取L图形
        AbstractBox box2 = BoxFactory.getInstance().getShape("L");
        box2.display("Red");

        // 再次获取L图形，但是是不同颜色
        AbstractBox box3 = BoxFactory.getInstance().getShape("L");
        box3.display("Green");

        System.out.println(box2 == box3); // true
    }
}

5.7.4 优缺点和使用场景

优点
- 极大减少内存中相似或相同对象数量，节约系统资源，提供系统性能
- 享元模式中的外部状态相对独立，且不影响内部状态（例如上例中的颜色，就是外部状态）
缺点
- 为了使对象可以共享，需要将享元对象的部分状态外部化，分离内部状态和外部状态，使程序逻辑复杂
使用场景
- 一个系统有大量相同或者相似的对象，造成内存的大量耗费。
- 对象的大部分状态都可以外部化，可以将这些外部状态传入对象中。
- 在使用享元模式时需要维护一个存储享元对象的享元池，而这需要耗费一定的系统资源，因此，应当在需要多次重复使用享元对象时才值得使用享元模式。

5.7.5 源码解析

Integer类使用了享元模式。

public class Demo {
	public static void main(String[] args) {
		Integer i1 = 127;
		Integer i2 = 127;
		System.out.println("i1和i2对象是否是同一个对象？" + (i1 == i2)); // true
        
		Integer i3 = 128;
		Integer i4 = 128;
		System.out.println("i3和i4对象是否是同一个对象？" + (i3 == i4)); // false
	}
}

通过反编译软件进行反编译，代码如下：

public class Demo {
	public static void main(String[] args) {
		Integer i1 = Integer.valueOf((int)127); // 底层使用valueOf方法
		Integer i2 = Integer.valueOf((int)127);
		System.out.println((String)new		StringBuilder().append((String)"i1\u548ci2\u5bf9\u8c61\u662f\u5426\u662f\u540c\u4e00\u4e2a\u5bf9\u8c61\uff1f").append((boolean)(i1 ==i2)).toString());
        
		Integer i3 = Integer.valueOf((int)128); // 底层使用valueOf方法
		Integer i4 = Integer.valueOf((int)128);
		System.out.println((String)new StringBuilder().append((String)"i3\u548ci4\u5bf9\u8c61\u662f\u5426\u662f\u5 40c\u4e00\u4e2a\u5bf9\u8c61\uff1f").append((boolean)(i3 ==i4)).toString());
	}
}

上面代码可以看到，直接给Integer类型的变量赋值基本数据类型数据的操作底层使用的是valueOf() ，所以只需要看该方法即可：

public final class Integer extends Number implements Comparable<Integer> {
	public static Integer valueOf(int i) {
		if (i >= IntegerCache.low && i <= IntegerCache.high)
            //  -128 ~ 127 ，直接从缓存IntegerCache.cache中返回
			return IntegerCache.cache[i + (-IntegerCache.low)];
       	// 否则新建对象
		return new Integer(i);
	}
	private static class IntegerCache {
		static final int low = -128;
		static final int high;
		static final Integer cache[];
        static {
			int h = 127;
			String integerCacheHighPropValue = sun.misc.VM.getSavedProperty("java.lang.Integer.IntegerCache.high");
			if (integerCacheHighPropValue != null) {
				try {
					int i = parseInt(integerCacheHighPropValue);
					i = Math.max(i, 127);
					// Maximum array size is Integer.MAX_VALUE
					h = Math.min(i, Integer.MAX_VALUE - (-low) -1);
				} catch( NumberFormatException nfe) {
                    
                }
			}
			high = h;
			cache = new Integer[(high - low) + 1];
			int j = low;
			for(int k = 0; k < cache.length; k++)
				cache[k] = new Integer(j++);
				// range [-128, 127] must be interned (JLS7 5.1.7)
			assert IntegerCache.high >= 127;
		}
	}
}

可以看到 Integer 默认先创建并缓存 -128 ~ 127 之间数的 Integer 对象，当调用 valueOf时如果参数在 -128 ~ 127 之间则计算下标并从缓存中返回，否则创建一个新的 Integer 对象。

6 行为型模式

行为型模式用于描述程序在运行时复杂的流程控制，即描述多个类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，它涉及算法与对象间职责的分配。

行为型模式分为类行为模式和对象行为模式，前者采用继承机制来在类间分派行为，后者采用组合或聚合在对象间分配行为。由于组合关系或聚合关系比继承关系耦合度低，满足“合成复用原则”，所以对象行为模式比类行为模式具有更大的灵活性。

6.1 模板方法模式

6.1.1 概述

在面向对象程序设计过程中，程序员常常会遇到这种情况：设计一个系统时知道了算法所需的关键步骤，而且确定了这些步骤的执行顺序，但某些步骤的具体实现还未知，或者说某些步骤的实现与具体的环境相关。

例如，去银行办理业务一般要经过以下4个流程：取号、排队、办理具体业务、对银行工作人员进行评分等，其中取号、排队和对银行工作人员进行评分的业务对每个客户是一样的，可以在父类中实现，但是办理具体业务却因人而异，它可能是存款、取款或者转账等，可以延迟到子类中实现。

定义：定义一个操作中的算法骨架，而将算法的一些步骤延迟到子类中，使得子类可以不改变该算法结构的情况下重定义该算法的某些特定步骤。

6.1.2 结构

模板方法（Template Method）模式包含以下主要角色：

抽象类（Abstract Class）：负责给出一个算法的轮廓和骨架。它由一个模板方法和若干个基本方法构成。
- 模板方法：定义了算法的骨架，按某种顺序调用其包含的基本方法。
- 基本方法：是实现算法各个步骤的方法，是模板方法的组成部分。基本方法又可以分为三种：
  - 抽象方法(Abstract Method) ：一个抽象方法由抽象类声明、由其具体子类实现。
  - 具体方法(Concrete Method) ：一个具体方法由一个抽象类或具体类声明并实现，其子类可以进行覆盖也可以直接继承。
  - 钩子方法(Hook Method) ：在抽象类中已经实现，包括用于判断的逻辑方法和需要子类重写的空方法两种。一般钩子方法是用于判断的逻辑方法，这类方法名一般为isXxx，返回值类型为boolean类型。
具体子类（Concrete Class）：实现抽象类中所定义的抽象方法和钩子方法，它们是一个顶级逻辑的组成步骤。

6.1.3 实现

【例】炒菜

炒菜的步骤是固定的，分为倒油、热油、倒蔬菜、倒调料品、翻炒等步骤。现通过模板方法模式来用代码模拟。类图如下：

代码实现

抽象类

// 抽象类：模板方法和基本方法
public abstract class AbstractClass {

  // 模板方法，一般加上final，防止子类修改
  public final void cookProcess() {
    // 按照顺序执行方法
    pourOil();
    heatOil();
    pourVegetable();
    pourSauce();
    fry();
  }

  // 基本方法（具体方法）
  public void pourOil() {
    System.out.println("倒油");
  }

  // 基本方法（具体方法）
  public void heatOil() {
    System.out.println("热油");
  }

  // 基本方法（抽象方法）:需要子类自己实现
  public abstract void pourVegetable();

  // 基本方法（抽象方法）
  public abstract void pourSauce();

  // 基本方法（具体方法）
  public void fry() {
    System.out.println("翻炒");
  }
}

具体子类

// 具体实现类
public class ConcreteClass_BaoCai extends AbstractClass{
    @Override
    public void pourVegetable() {
        System.out.println("蔬菜是包菜");
    }

    @Override
    public void pourSauce() {
        System.out.println("调料是辣椒");
    }
}

// 具体实现类
public class ConcreteClass_CaiXin extends AbstractClass{
    @Override
    public void pourVegetable() {
        System.out.println("蔬菜是菜心");
    }

    @Override
    public void pourSauce() {
        System.out.println("调料是蒜蓉");
    }
}

测试类

public class Test {
    public static void main(String[] args) {
        // 炒包菜
        ConcreteClass_BaoCai baoCai = new ConcreteClass_BaoCai();
        // 调用抽象父类中的模板方法
        baoCai.cookProcess();
    }
}

打印结果：

倒油
热油
蔬菜是包菜
调料是辣椒
翻炒

6.1.4 总结

优缺点

优点：

提高代码复用性：将相同部分的代码放在抽象的父类中，而将不同的代码放入不同的子类中
实现了反向控制：通过一个父类调用其子类的操作，通过对子类的具体实现扩展不同的行为，实现了反向控制，并符合“开闭原则”。

缺点：

对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。
父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度。

使用场景

算法的整体步骤很固定，但其中个别部分易变时，这时候可以使用模板方法模式，将容易变的部分抽象出来，供子类实现。
需要通过子类来决定父类算法中某个步骤是否执行，实现子类对父类的反向控制。

6.1.5 源码解析

InputStream类就使用了模板方法模式。在InputStream类中定义了多个 read() 方法，如下：

public abstract class InputStream implements Closeable {
	// 抽象方法，要求子类必须重写
	public abstract int read() throws IOException;
    
	public int read(byte b[]) throws IOException {
		return read(b, 0, b.length);
	}
    
	public int read(byte b[], int off, int len) throws IOException {
		if (b == null) {
			throw new NullPointerException();
		} else if (off < 0 || len < 0 || len > b.length - off) {
			throw new IndexOutOfBoundsException();
		} else if (len == 0) {
			return 0;
		}
		int c = read(); //调用了无参的read方法，该方法是每次读取一个字节数据
		if (c == -1) {
			return -1;
		}
		b[off] = (byte)c;
		int i = 1;
		try {
			for (; i < len ; i++) {
				c = read();
				if (c == -1) {
					break;
				}
				b[off + i] = (byte)c;
			}
		} catch (IOException ee) {
		}
		return i;
	}
}

从上面代码可以看到，无参的 read() 方法是抽象方法，要求子类必须实现。而 read(byte b[])方法调用了 read(byte b[], int off, int len) 方法，所以在此处重点看的方法是带三个参数的方法。

在该方法中第17行、25行，可以看到调用了无参的抽象的 read() 方法。

总结如下：在InputStream父类中已经定义好了读取一个字节数组数据的方法是每次读取一个字节，并将其存储到数组的第一个索引位置，读取len个字节数据。具体如何读取一个字节数据呢？由子类实现。

6.2 策略模式

6.2.1 概述

作为一个程序猿，开发需要选择一款开发工具，当然可以进行代码开发的工具有很多，可以选择Idea进行开发，也可以使用eclipse进行开发，也可以使用其他的一些开发工具。

定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。

6.2.2 结构

策略模式的主要角色如下：

抽象策略（Strategy）类：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。
具体策略（Concrete Strategy）类：实现了抽象策略定义的接口，提供具体的算法实现或行为。
环境（Context）类：持有一个策略类的引用（聚合策略类对象），最终给客户端调用。

6.2.3 实现

场景1

【例】促销活动

一家百货公司在定年度的促销活动。针对不同的节日（春节、中秋节、圣诞节）推出不同的促销活动，由促销员将促销活动展示给客户。类图如下：

代码实现

抽象策略类

// 抽象策略接口
public interface Strategy {
  void show();
}

具体策略类

// 具体策略类
public class StrategyA implements Strategy{
  @Override
  public void show() {
    System.out.println("买一送一");
  }
}

// 具体策略类
public class StrategyB implements Strategy{
  @Override
  public void show() {
    System.out.println("买200减50");
  }
}

环境类

// 环境类
public class SalesMan {
  // 聚合策略类
  private Strategy strategy;
  // 构造方法，传入具体策略类
  public SalesMan(Strategy strategy) {
    this.strategy = strategy;
  }

  // 由促销员展示促销活动给用户
  public void salesManShow() {
    strategy.show();
  }
}

测试

public class Test {
  public static void main(String[] args) {
    SalesMan salesMan = new SalesMan(new StrategyA());
    salesMan.salesManShow(); // 买一送一
  }
}

场景2

计算快递的费用：

距离单价price
一个最小距离minDistance，小于该距离的以此距离计算
额外费用extra

现在的业务场景只有一种快递，例如京东快递。

运费实体：TransferFee

@Data
@Getter
public class TransferFee {
  // 距离
  private BigDecimal distance;
	// 单价
  private BigDecimal unitPrice;
}

业务类接口和实现类

1
2
3

public interface ITransferFeeService {
  BigDecimal calculateTransferFee(TransferFee transferFee);
}

@Service
public class TransferFeeServiceImpl implements ITransferFeeService {
	// 额外运费
  private final BigDecimal extra = BigDecimal.TEN;
	// 最小距离
  private final BigDecimal minDistance = BigDecimal.valueOf(80);

  @Override
  public BigDecimal calculateTransferFee(TransferFee transferFee) {
    BigDecimal distance = minDistance.compareTo(transferFee.getDistance()) > 0 ? minDistance : transferFee.getDistance();
    return distance.multiply(transferFee.getUnitPrice()).add(extra);
  }
}

控制器

@RestController
@RequestMapping("/fee")
public class TransferFeeController {

  @Autowired
  private ITransferFeeService transferFeeService;

  @GetMapping("/cal")
  public ResponseResult<BigDecimal> calculateTransferFee(@RequestBody TransferFee transferFee) {
    BigDecimal fee = transferFeeService.calculateTransferFee(transferFee);
    return ResponseResult.success(fee);
  }
}

测试：

{
  "distance": 10,
  "unitPrice": 10
}

{
  "timestamp": 1699067387740,
  "status": "200",
  "message": "success",
  "data": 810 // 80 * 10 + 10
}

现在新增了一种快递，例如顺丰，它的额外费用和最小距离都不同，于是在运费类中新增字段type表示快递种类，业务类也需要改变。

运费类

@Data
@Getter
public class TransferFee {
  private BigDecimal distance;

  private BigDecimal unitPrice;

  private Integer type;
}

业务类

@Service
public class TransferFeeServiceImpl implements ITransferFeeService {
	// 京东
  private final BigDecimal extra = BigDecimal.TEN;

  private final BigDecimal minDistance = BigDecimal.valueOf(80);
	
  // 顺丰
  private final BigDecimal extra2 = BigDecimal.valueOf(5);

  private final BigDecimal minDistance2 = BigDecimal.valueOf(70);

  @Override
  public BigDecimal calculateTransferFee(TransferFee transferFee) {
    if (transferFee.getType() == null || transferFee.getType() == 1) { // 京东
      BigDecimal distance = minDistance.compareTo(transferFee.getDistance()) > 0 ? minDistance : transferFee.getDistance();
      return distance.multiply(transferFee.getUnitPrice()).add(extra);
    } else if (transferFee.getType() == 2) { // 顺丰
      BigDecimal distance = minDistance2.compareTo(transferFee.getDistance()) > 0 ? minDistance2 : transferFee.getDistance();
      return distance.multiply(transferFee.getUnitPrice()).add(extra2);
    }
    return null;
  }
}

测试：

{
  "distance": 10,
  "unitPrice": 10,
  "type": 2
}

问题分析：

如果之后快递类型继续增加，会导致if-else块越来越多，不符合开闭原则。

使用策略模式进行优化。实现同一个接口的不同业务，采用多个实现类的形式（缺点：类爆炸）。

项目结构：

控制器在注入的时候，需要注入ITransferFeeService的List结构（或者Map）。控制器需要知道是哪一个业务的service，因此需要在接口中定义方法：

boolean isCurrentTransfer(Integer type);

// 实现
@Override
public boolean isCurrentTransfer(Integer type) {
  return type == 1; // 京东，这里建议使用枚举
}

@Override
public boolean isCurrentTransfer(Integer type) {
  return type == 2; // 顺丰
}

// ...

控制器：

@RestController
@RequestMapping("/fee")
public class TransferFeeController {
	
  // 注入一个List的transferFeeService
  @Autowired
  private List<ITransferFeeService> transferFeeService;

  @GetMapping("/cal")
  public ResponseResult<BigDecimal> calculateTransferFee(@RequestBody TransferFee transferFee) {
    Integer type = transferFee.getType();
    // 筛选
    ITransferFeeService feeService = transferFeeService.stream().filter(l -> l.isCurrentTransfer(type)).findFirst().orElse(null);
    BigDecimal fee = feeService.calculateTransferFee(transferFee);
    return ResponseResult.success(fee);
  }
}

6.2.4 总结

优缺点

优点：

策略类之间可以自由切换：由于策略类都实现同一个接口，所以使它们之间可以自由切换。
易于扩展：增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合“开闭原则“
避免使用多重条件选择语句（if else），充分体现面向对象设计思想。

缺点：

客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
策略模式将造成产生很多策略类（类爆炸），可以通过使用享元模式在一定程度上减少对象的数量。

使用场景

一个系统需要动态地在几种算法中选择一种时，可将每个算法封装到策略类中。
一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，可将每个条件分支移入它们各自的策略类中以代替这些条件语句。
系统中各算法彼此完全独立，且要求对客户隐藏具体算法的实现细节时。
系统要求使用算法的客户不应该知道其操作的数据时，可使用策略模式来隐藏与算法相关的数据结构。
多个类只区别在表现行为不同，可以使用策略模式，在运行时动态选择具体要执行的行为。

6.2.5 源码解析

Comparator 中的策略模式。在Arrays类中有一个 sort() 方法，如下：

public class Arrays{
	public static <T> void sort(T[] a, Comparator<? super T> c) {
		if (c == null) {
			sort(a);
		} else {
			if (LegacyMergeSort.userRequested)
				legacyMergeSort(a, c);
			else
				TimSort.sort(a, 0, a.length, c, null, 0, 0);
		}
	}
}

Arrays就是一个环境角色类，这个sort方法可以传一个新策略让Arrays根据这个策略来进行排序。就比如下面的测试类。

public class demo {
	public static void main(String[] args) {
		Integer[] data = {12, 2, 3, 2, 4, 5, 1};
		// 实现降序排序
		Arrays.sort(data, new Comparator<Integer>() {
			public int compare(Integer o1, Integer o2) {
				return o2 - o1;
			}
		});
		System.out.println(Arrays.toString(data)); //[12, 5, 4, 3, 2, 2, 1]
	}
}

这里我们在调用Arrays的sort方法时，第二个参数传递的是Comparator接口的子实现类对象。所以Comparator充当的是抽象策略角色，而具体的子实现类充当的是具体策略角色。环境角色类（Arrays）应该持有抽象策略的引用来调用。

设计模式学习笔记(新)

设计模式学习笔记

1 概述

1.1 产生背景

1.2 概念

1.3 分类

2 UML类图

2.1 概述

2.2 表示法

2.2.1 类的表示方式

2.2.2 类之间关系的表示方式

① 关联关系

② 聚合关系

③ 组合关系

④ 依赖关系

⑤ 继承关系

⑥ 实现关系

3 软件设计原则

3.1 开闭原则

3.2 里氏代换原则

3.3 依赖倒转原则

3.4 接口隔离原则

3.5 迪米特法则

3.6 合成复用原则

4 创建者模式

4.1 单例设计模式

4.1.1 结构

4.1.2 实现

① 饿汉式-方式1（静态变量方式）

② 饿汉式-方式2（静态代码块方式）

③ 懒汉式-方式1（线程不安全）

④ 懒汉式-方式2（线程安全）

⑤ 懒汉式-方式3（双重检查锁）

⑥ 懒汉式-方式4（静态内部类方式）

⑦ 饿汉式-方式3（枚举）

4.1.3 问题

4.1.4 Runtime类

4.2 工厂模式

4.2.1 概述

4.2.2 简单工厂模式

① 结构

② 实现

③ 优缺点

④ 扩展

4.2.3 工厂方法模式

① 结构

② 实现

③ 优缺点

4.2.4 抽象工厂模式

① 结构

② 实现

③ 优缺点

4.2.5 模式扩展

4.2.6 Collection.iterator方法

4.3 原型模式

4.3.1 结构

4.3.2 实现

4.3.3 案例

4.3.4 使用场景

4.4 建造者模式

4.4.1 简介

4.4.2 结构

4.4.3 案例

4.4.4 优缺点

4.4.5 使用场景

4.4.6 模式扩展

4.5 创建者模式对比

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

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

5 结构型模式

5.1 代理模式

5.1.1 简介

5.1.2 结构

5.1.3 静态代理

5.1.4 JDK动态代理

① 实现

② 原理

③ 执行流程

5.1.5 CGLIB动态代理

5.1.6 三种代理对比