【计算机基础】23种设计模式

23种设计模式

时间：2021年11月12日10:36:16

作者：聪头

URL：http://c.biancheng.net/design_pattern/

• 个人认为（在游戏开发中）比较常用或重要的设计模式，会使用☆标识
• 推荐先看概述，缺点看完后看结构与实现，再倒回去看应用场景和扩展

总结：一句话归纳设计模式

设计模式概述

分类

根据目的来分

创建型模式：5种。用于描述“怎样创建对象”，它的主要特点是“将对象的创建于使用分离”

• 单例、原型、工厂方法、抽象工厂、建造者

结构型模式：7种。用于描述如何将类或对象按某种布局组成更大的结构

• 代理、适配器、桥接、装饰、外观、享元、组合

行为型模式：11种。用于描述类或对象之间怎样相互协作共同完成单个对象都无法单独完成的任务，以及怎样分配职责

• 模板方法、策略、命令、职责链、状态、观察者、中介者、迭代器、访问者、备忘录、解释器

根据作用范围来分

类模式：4种。用于处理类与子类之间的关系，这些关系通过继承来建立，是静态的，在编译时刻便确定下来了

• 工厂方法、（类）适配器、模板方法、解释器

对象模式：其他都是。用于处理对象之间的关系，这些关系可以通过组合或聚合来实现，在运行时刻是可以变化的，更具动态性

UML

概述

UML（Unified Modeling Language，统一建模语言）是用来设计软件蓝图的可视化建模语言，是一种为面向对象系统的产品进行说明、可视化和编制文档的标准语言，独立于任何一种具体的程序设计语言。

1997 年 UML 被国际对象管理组织（OMG）采纳为面向对象的建模语言的国际标准。它的特点是简单、统一、图形化、能表达软件设计中的动态与静态信息。

详见：http://c.biancheng.net/view/8373.html

组成

UML 建模的核心是模型，模型是现实的简化、真实系统的抽象。UML 提供了系统的设计蓝图。当给软件系统建模时，需要采用通用的符号语言，这种描述模型所使用的语言被称为建模语言。在 UML 中，所有的描述由事物、关系和图这些构件组成。下图完整地描述了所有构件的关系。

类、接口和类图

在 UML 2.0 的 13 种图中，类图（Class Diagrams）是使用频率最高的 UML 图之一。类图描述系统中的类，以及各个类之间的关系的静态视图，能够让我们在正确编写代码之前对系统有一个全面的认识。类图是一种模型类型，确切地说，是一种静态模型类型。类图表示类、接口和它们之间的协作关系，用于系统设计阶段。

1. 类

类（Class）是指具有相同属性、方法和关系的对象的抽象，它封装了数据和行为，是面向对象程序设计（OOP）的基础，具有封装性、继承性和多态性等三大特性。在 UML 中，类使用包含类名、属性和操作且带有分隔线的矩形来表示。

(1) 类名（Name）是一个字符串，例如，Student。

(2) 属性（Attribute）是指类的特性，即类的成员变量。UML 按以下格式表示：

[可见性]属性名:类型[=默认值]

例如：-name:String

• 注意：“可见性”表示该属性对类外的元素是否可见，包括公有（Public）、私有（Private）、受保护（Protected）和朋友（Friendly）4 种，在类图中分别用符号+、-、#、~表示。

(3) 操作（Operations）是类的任意一个实例对象都可以使用的行为，是类的成员方法。UML 按以下格式表示：

[可见性]名称(参数列表)[:返回类型]

例如：+display():void。

举例：学生类的UML

类图用 3 个矩形拼接表示，最上面的部分标识类的名称，中间的部分标识类的属性，最下面的部分标识类的方法。

注意点：

• 抽象类或抽象方法用斜体表示
• 如果是接口，则在类名上方加 <<Interface>>
• 字段和方法返回值的数据类型非必需
• 静态类或静态方法加下划线

2.接口

接口（Interface）是一种特殊的类，它具有类的结构但不可被实例化，只可以被子类实现。它包含抽象操作，但不包含属性。它描述了类或组件对外可见的动作。在 UML 中，接口使用一个带有名称的小圆圈来进行表示。

举例：图形类接口的UML

3.类图

类图（ClassDiagram）是用来显示系统中的类、接口、协作以及它们之间的静态结构和关系的一种静态模型。它主要用于描述软件系统的结构化设计，帮助人们简化对软件系统的理解，它是系统分析与设计阶段的重要产物，也是系统编码与测试的重要模型依据。

类图中的类可以通过某种编程语言直接实现。类图在软件系统开发的整个生命周期都是有效的，它是面向对象系统的建模中最常见的图。

举例：如下所示是“计算长方形和圆形的周长与面积”的类图，图形接口有计算面积和周长的抽象方法，长方形和圆形实现这两个方法供访问类调用

类之间关系

UML 将事物之间的联系归纳为 6 种，并用对应的图形类表示。下面根据类与类之间的耦合度从弱到强排列。UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。

说明：虚线表示类内部实现，不代表任何关系

1.依赖关系！

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

在 UML 类图中，依赖关系使用带箭头的虚线来表示，箭头从使用类指向被依赖的类。如下是人与手机的关系图，人通过手机的语音传送方法打电话。

2.关联关系

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

关联可以是双向的，也可以是单向的。在 UML 类图中，双向的关联可以用带两个箭头或者没有箭头的实线来表示，单向的关联用带一个箭头的实线来表示，箭头从使用类指向被关联的类。也可以在关联线的两端标注角色名，代表两种不同的角色。

3.聚合关系

聚合（Aggregation）关系是关联关系的一种，是强关联关系，是整体和部分之间的关系，是 has-a 的关系。

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

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

4.组合关系！

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

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

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

5.泛化关系！

泛化（Generalization）关系是对象之间耦合度最大的一种关系，表示一般与特殊的关系，是父类与子类之间的关系，是一种继承关系，是 is-a 的关系。

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

6.实现关系！

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

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

面向对象设计七大原则

目的总结：降低对象之间的耦合，增加程序的可复用性、可扩展性和可维护性

建议：在程序设计时，我们应该将程序功能最小化，每个类只干一件事。若有类似功能基础之上添加新功能，则要合理使用继承。对于多方法的调用，要会运用接口，同时合理设置接口功能与数量。最后类与类之间做到低耦合高内聚

———- 创建型模式 ———-

创建型模式的主要关注点是“怎样创建对象？”，它的主要特点是“将对象的创建与使用分离”。这样可以降低系统的耦合度，使用者不需要关注对象的创建细节，对象的创建由相关的工厂来完成。就像我们去商场购买商品时，不需要知道商品是怎么生产出来一样，因为它们由专门的厂商生产。

1.单例模式 ☆

概述

引入：在有些系统中，为了节省内存资源、保证数据内容的一致性，对某些类要求只能创建一个实例，这就是所谓的单例模式。

定义：指一个类只有一个实例，且该类能自行创建这个实例的一种模式

特点：

• 单例类只有一个实例对象
• 该单例对象必须由单例类自行创建
• 单例类对外提供一个访问该单例的全局访问点

优点：

• 单例模式可以保证内存里只有一个实例，减少了内存的开销。
• 可以避免对资源的多重占用。
• 单例模式设置全局访问点，可以优化和共享资源的访问。

缺点：

• 单例模式一般没有接口，扩展困难。如果要扩展，则除了修改原来的代码，没有第二种途径，违背开闭原则。
• 在并发测试中，单例模式不利于代码调试。在调试过程中，如果单例中的代码没有执行完，也不能模拟生成一个新的对象。
• 单例模式的功能代码通常写在一个类中，如果功能设计不合理，则很容易违背单一职责原则。

应用场景：

• 需要频繁创建的一些类，使用单例可以降低系统的内存压力，减少 GC。
• 某类只要求生成一个对象的时候，如一个班中的班长、每个人的身份证号等。
• 某些类创建实例时占用资源较多，或实例化耗时较长，且经常使用。
• 某类需要频繁实例化，而创建的对象又频繁被销毁的时候，如多线程的线程池、网络连接池等。
• 频繁访问数据库或文件的对象。
• 对于一些控制硬件级别的操作，或者从系统上来讲应当是单一控制逻辑的操作，如果有多个实例，则系统会完全乱套。
• 当对象需要被共享的场合。由于单例模式只允许创建一个对象，共享该对象可以节省内存，并加快对象访问速度。如 Web 中的配置对象、数据库的连接池等。

扩展：

• 单例模式可扩展为有限的多例（Multitcm）模式，这种模式可生成有限个实例并保存在 ArrayList 中，客户需要时可随机获取

结构与实现

单例模式是设计模式中最简单的模式之一。通常，普通类的构造函数是公有的，外部类可以通过“new 构造函数()”来生成多个实例。但是，如果将类的构造函数设为私有的，外部类就无法调用该构造函数，也就无法生成多个实例。这时该类自身必须定义一个静态私有实例，并向外提供一个静态的公有函数用于创建或获取该静态私有实例。下面来分析其基本结构和实现方法。

单例模式的的主要角色如下：

• 单例类：包含一个实例且能自行创建这个实例的类（以下示例只给出单例类的写法）
• 访问类：使用单例的类。

懒汉式

要点：类加载时没有生成单例，只有当第一次调用 getlnstance 方法时才去创建这个单例

优点：延迟加载

缺点：如果编写的是多线程程序，则不要删除代码中的关键字 volatile 和 synchronized，否则将存在线程非安全的问题。但是每次访问时都要同步，会影响性能，且消耗更多的资源，这是懒汉式单例的缺点。

public class LazySingleton {
  //保证 instance 在所有线程中同步
  private static volatile LazySingleton instance = null;    
  private LazySingleton() {
  }    //private 避免类在外部被实例化
  public static synchronized LazySingleton getInstance() {
    //getInstance 方法前加同步
    if (instance == null) {
      instance = new LazySingleton();
    }
    return instance;
  }
}

饿汉式

要点：类一旦加载就创建一个单例，保证在调用 getInstance 方法之前单例已经存在了

优点：在类创建的同时就已经创建好一个静态的对象供系统使用，以后不再改变，所以是线程安全的，可以直接用于多线程而不会出现问题

缺点：不可延迟加载

public class HungrySingleton {
  private static final HungrySingleton instance = new HungrySingleton();
  private HungrySingleton() {
  }
  public static HungrySingleton getInstance() {
    return instance;
  }
}

2.原型模式 ☆

概述

引入：在有些系统中，存在大量相同或相似对象的创建问题，如果用传统的构造函数来创建对象，会比较复杂且耗时耗资源，用原型模式生成对象就很高效，就像孙悟空拔下猴毛轻轻一吹就变出很多孙悟空一样简单。

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

优点：

• Java 自带的原型模式基于内存二进制流的复制，在性能上比直接 new 一个对象更加优良。
• 可以使用深克隆方式保存对象的状态，使用原型模式将对象复制一份，并将其状态保存起来，简化了创建对象的过程，以便在需要的时候使用（例如恢复到历史某一状态），可辅助实现撤销操作。

缺点：

• 需要为每一个类都配置一个 clone 方法
• clone 方法位于类的内部，当对已有类进行改造的时候，需要修改代码，违背了开闭原则。
• 当实现深克隆时，需要编写较为复杂的代码，而且当对象之间存在多重嵌套引用时，为了实现深克隆，每一层对象对应的类都必须支持深克隆，实现起来会比较麻烦。因此，深克隆、浅克隆需要运用得当。

应用场景：

• 对象之间相同或相似，即只是个别的几个属性不同的时候。
• 创建对象成本较大，例如初始化时间长，占用CPU太多，或者占用网络资源太多等，需要优化资源。
• 创建一个对象需要繁琐的数据准备或访问权限等，需要提高性能或者提高安全性。
• 系统中大量使用该类对象，且各个调用者都需要给它的属性重新赋值。

扩展：

• 原型模式可扩展为带原型管理器的原型模式，它在原型模式的基础上增加了一个原型管理器 PrototypeManager 类。该类用 HashMap 保存多个复制的原型，Client 类可以通过管理器的 get(String id) 方法从中获取复制的原型

结构与实现

由于Java提供了对象的clone方法，所以用Java实现原型模式很简单

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

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

原型模式的主要角色如下：

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

Java 中的 Object 类提供了浅克隆的 clone() 方法，具体原型类只要实现 Cloneable 接口就可实现对象的浅克隆，这里的 Cloneable 接口就是抽象原型类。其代码如下：

//具体原型类
class Realizetype implements Cloneable {
  public Realizetype() {
    System.out.println("具体原型创建成功！");
  }
  public Object clone() throws CloneNotSupportedException {
    System.out.println("具体原型复制成功！");
    return (Realizetype) super.clone();
  }
}
//原型模式的测试类
public class PrototypeTest {
  public static void main(String[] args) throws CloneNotSupportedException {
    Realizetype obj1 = new Realizetype();
    Realizetype obj2 = (Realizetype) obj1.clone();
    System.out.println("obj1==obj2?" + (obj1 == obj2));
  }
}

输出：

具体原型创建成功！
具体原型复制成功！
obj1==obj2?false

补：简单工厂模式 ☆

简单工厂模式不再GoF 23种设计模式之列

概述

引入：现实生活中，原始社会自给自足（没有工厂），农耕社会小作坊（简单工厂，民间酒坊），工业革命流水线（工厂方法，自产自销），现代产业链代工厂（抽象工厂，富士康）。我们的项目代码同样是由简到繁一步一步迭代而来的，但对于调用者来说，却越来越简单。

定义：定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类中

• 通俗来讲：有一个具体的工厂类，可以生成多个不同的产品

优点：

1. 工厂类包含必要的逻辑判断，可以决定在什么时候创建哪一个产品的实例。客户端可以免除直接创建产品对象的职责，很方便的创建出相应的产品。工厂和产品的职责区分明确。
2. 客户端无需知道所创建具体产品的类名，只需知道参数即可。
3. 也可以引入配置文件，在不修改客户端代码的情况下更换和添加新的具体产品类。

缺点：

1. 简单工厂模式的工厂类单一，负责所有产品的创建，职责过重，一旦异常，整个系统将受影响。且工厂类代码会非常臃肿，违背高聚合原则。
2. 使用简单工厂模式会增加系统中类的个数（引入新的工厂类），增加系统的复杂度和理解难度
3. 系统扩展困难，一旦增加新产品不得不修改工厂逻辑，在产品类型较多时，可能造成逻辑过于复杂（违背开闭原则）
4. 简单工厂模式使用了 static 工厂方法，造成工厂角色无法形成基于继承的等级结构。

应用场景：

• 对于产品种类相对较少的情况，考虑使用简单工厂模式。使用简单工厂模式的客户端只需要传入工厂类的参数，不需要关心如何创建对象的逻辑，可以很方便地创建所需产品。

结构与实现

简单工厂模式的主要角色如下：

• 简单工厂（SimpleFactory）：是简单工厂模式的核心，负责实现创建所有实例的内部逻辑。工厂类的创建产品类的方法可以被外界直接调用，创建所需的产品对象。
• 抽象产品（Product）：是简单工厂创建的所有对象的父类，负责描述所有实例共有的公共接口。
• 具体产品（ConcreteProduct）：是简单工厂模式的创建目标。

public class Client {
  public static void main(String[] args) {
  }
  //抽象产品
  public interface Product {
    void show();
  }
  //具体产品：ProductA
  static class ConcreteProduct1 implements Product {
    public void show() {
      System.out.println("具体产品1显示...");
    }
  }
  //具体产品：ProductB
  static class ConcreteProduct2 implements Product {
    public void show() {
      System.out.println("具体产品2显示...");
    }
  }
  final class Const {
    static final int PRODUCT_A = 0;
    static final int PRODUCT_B = 1;
    static final int PRODUCT_C = 2;
  }
  //简单工厂
  static class SimpleFactory {
    public static Product makeProduct(int kind) {
      switch (kind) {
        case Const.PRODUCT_A:
          return new ConcreteProduct1();
        case Const.PRODUCT_B:
          return new ConcreteProduct2();
      }
      return null;
    }
  }
}

3.工厂方法模式 ☆

概述

引入：在现实生活中社会分工越来越细，越来越专业化。各种产品有专门的工厂生产，彻底告别了自给自足的小农经济时代，这大大缩短了产品的生产周期，提高了生产效率。同样，在软件开发中能否做到软件对象的生产和使用相分离呢？能否在满足“开闭原则”的前提下，客户随意增删或改变对软件相关对象的使用呢？这就是本节要讨论的问题。

定义：对简单工厂模式的进一步抽象化，使其在不修改原来代码的情况下引进新的产品，满足开闭原则

优点：

• 用户只需要知道具体工厂的名称就可得到所要的产品，无须知道产品的具体创建过程。
• 灵活性增强，对于新产品的创建，只需多写一个相应的工厂类。
• 典型的解耦框架。高层模块只需要知道产品的抽象类，无须关心其他实现类，满足迪米特法则、依赖倒置原则和里氏替换原则。

缺点：

• 类的个数容易过多，增加复杂度
• 增加了系统的抽象性和理解难度
• 抽象产品只能生产一种产品，此弊端可使用抽象工厂模式解决。

应用场景：

• 客户只知道创建产品的工厂名，而不知道具体的产品名。如 TCL 电视工厂、海信电视工厂等。
• 创建对象的任务由多个具体子工厂中的某一个完成，而抽象工厂只提供创建产品的接口。
• 客户不关心创建产品的细节，只关心产品的品牌

结构与实现

工厂方法模式的主要角色如下。

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

package FactoryMethod;

public class AbstractFactoryTest {
  public static void main(String[] args) {
    try {
      Product a;
      AbstractFactory af;
      af = (AbstractFactory) ReadXML1.getObject(); //获得具体的工厂
      a = af.newProduct(); //生成该工厂的产品
      a.show();
    } catch (Exception e) {
      System.out.println(e.getMessage());
    }
  }
}

//抽象产品：提供了产品的接口
interface Product {
  public void show();
}

//具体产品1：实现抽象产品中的抽象方法
class ConcreteProduct1 implements Product {
  public void show() {
    System.out.println("具体产品1显示...");
  }
}

//具体产品2：实现抽象产品中的抽象方法
class ConcreteProduct2 implements Product {
  public void show() {
    System.out.println("具体产品2显示...");
  }
}

//抽象工厂：提供了厂品的生成方法
interface AbstractFactory {
  public Product newProduct();
}

//具体工厂1：实现了厂品的生成方法
class ConcreteFactory1 implements AbstractFactory {
  public Product newProduct() {
    System.out.println("具体工厂1生成-->具体产品1...");
    return new ConcreteProduct1();
  }
}

//具体工厂2：实现了厂品的生成方法
class ConcreteFactory2 implements AbstractFactory {
  public Product newProduct() {
    System.out.println("具体工厂2生成-->具体产品2...");
    return new ConcreteProduct2();
  }
}

package FactoryMethod;
import javax.xml.parsers.*;
import org.w3c.dom.*;
import java.io.*;

class ReadXML1 {
  //该方法用于从XML配置文件中提取具体类类名，并返回一个实例对象
  public static Object getObject() {
    try {
      //创建文档对象
      DocumentBuilderFactory dFactory = DocumentBuilderFactory.newInstance();
      DocumentBuilder builder = dFactory.newDocumentBuilder();
      Document doc;
      doc = builder.parse(new File("src/FactoryMethod/config1.xml"));
      //获取包含类名的文本节点
      NodeList nl = doc.getElementsByTagName("className");
      Node classNode = nl.item(0).getFirstChild();
      String cName = "FactoryMethod." + classNode.getNodeValue(); //类的完全限定名
      //System.out.println("新类名："+cName);
      //通过类名生成实例对象并将其返回
      Class<?> c = Class.forName(cName);
      Object obj = c.newInstance();
      return obj;
    } catch (Exception e) {
      e.printStackTrace();
      return null;
    }
  }
}

<?xml version="1.0" encoding="UTF-8"?>
<config>
	<className>ConcreteFactory1</className>
</config>

输出

具体工厂1生成-->具体产品1...
具体产品1显示...

4.抽象工厂模式

概述

引入：

• 前面介绍的工厂方法模式中考虑的是一类产品的生产，如畜牧场只养动物、电视机厂只生产电视机、计算机软件学院只培养计算机软件专业的学生等。

• 同种类称为同等级，也就是说：工厂方法模式只考虑生产同等级的产品，但是在现实生活中许多工厂是综合型的工厂，能生产多等级（种类） 的产品，如农场里既养动物又种植物，电器厂既生产电视机又生产洗衣机或空调，大学既有软件专业又有生物专业等。

• 本节要介绍的抽象工厂模式将考虑多等级产品的生产，将同一个具体工厂所生产的位于不同等级的一组产品称为一个产品族

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

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

优点：

• 拥有工厂方法模式的优点。
• 可以在类的内部对产品族中相关联的多等级产品共同管理，而不必专门引入多个新的类来进行管理。
• 当需要产品族时，抽象工厂可以保证客户端始终只使用同一个产品的产品组。
• 抽象工厂增强了程序的可扩展性，当增加一个新的产品族时，不需要修改原代码，满足开闭原则。

缺点：

• 当产品族中需要增加一个新的产品时，所有的工厂类都需要进行修改。增加了系统的抽象性和理解难度。

结构与实现

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

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

(1) 抽象工厂：提供了产品的生成方法。

interface AbstractFactory {
  public Product1 newProduct1();
  public Product2 newProduct2();
}

(2) 具体工厂：实现了产品的生成方法

class ConcreteFactory1 implements AbstractFactory {
    public Product1 newProduct1() {
        System.out.println("具体工厂 1 生成-->具体产品 11...");
        return new ConcreteProduct11();
    }
    public Product2 newProduct2() {
        System.out.println("具体工厂 1 生成-->具体产品 21...");
        return new ConcreteProduct21();
    }
}

工厂模式比较

以下仅为个人看后的观点！

抽象工厂模式：

• 抽象工厂接口声明产品族的生产，即所有产品都需要生产

• 把具体工厂1 看作是高端工厂，生产的产品1,2为高端产品；同理，具体工厂2为低端工厂，生产的产品1,2为低端产品。那么，具体工厂1和2相当于负责产品族所有产品的生产，只是生产的产品质量不同罢了。

• 每当增加一个新的产品，就要同时修改抽象工厂接口类，加入新产品的生产方法。进而需要对所有具体工厂类进行修改

工厂方法模式：

• 抽象工厂接口仅声明一个产品的生产
• 具体工厂1仅生产一个产品，具体工厂2也仅生产一个产品。二者生产的产品通常情况下都是独立，互不影响的
• 每当增加一个新的产品，只需要创建一个具体工厂类去生产该产品即可

以上二者的结构基本相同，只是看待问题的角度略有不同罢了

简单工厂模式：

• 一个工厂负责所有产品的生产

5.建造者模式 ☆

概述

引入：

• 在软件开发过程中有时需要创建一个复杂的对象，这个复杂对象通常由多个子部件按一定的步骤组合而成。例如，计算机是由 CPU、主板、内存、硬盘、显卡、机箱、显示器、键盘、鼠标等部件组装而成的，采购员不可能自己去组装计算机，而是将计算机的配置要求告诉计算机销售公司，计算机销售公司安排技术人员去组装计算机，然后再交给要买计算机的采购员。

• 生活中这样的例子很多，如游戏中的不同角色，其性别、个性、能力、脸型、体型、服装、发型等特性都有所差异；还有汽车中的方向盘、发动机、车架、轮胎等部件也多种多样；每封电子邮件的发件人、收件人、主题、内容、附件等内容也各不相同。

• 以上所有这些产品都是由多个部件构成的，各个部件可以灵活选择，但其创建步骤都大同小异。这类产品的创建无法用前面介绍的工厂模式描述，只有建造者模式可以很好地描述该类产品的创建。

定义：指将一个复杂对象的构造与它的表示分离，使同样的构建过程可以创建不同的表示

优点：

1. 封装性好，构建和表示分离。
2. 扩展性好，各个具体的建造者相互独立，有利于系统的解耦。
3. 客户端不必知道产品内部组成的细节，建造者可以对创建过程逐步细化，而不对其它模块产生任何影响，便于控制细节风险。

缺点：

1. 产品的组成部分必须相同，这限制了其使用范围。
2. 如果产品的内部变化复杂，如果产品内部发生变化，则建造者也要同步修改，后期维护成本较大。

建造者（Builder）模式和工厂模式的关注点不同：建造者模式注重零部件的组装过程，而工厂方法模式更注重零部件的创建过程，但两者可以结合使用。

应用场景：

• 相同的方法，不同的执行顺序，产生不同的结果。
• 多个部件或零件，都可以装配到一个对象中，但是产生的结果又不相同。
• 产品类非常复杂，或者产品类中不同的调用顺序产生不同的作用。
• 初始化一个对象特别复杂，参数多，而且很多参数都具有默认值。

扩展：

• 建造者（Builder）模式在应用过程中可以根据需要改变，如果创建的产品种类只有一种，只需要一个具体建造者，这时可以省略掉抽象建造者，甚至可以省略掉指挥者角色。

结构与实现

建造者（Builder）模式的主要角色如下。

1. 产品角色（Product）：它是包含多个组成部件的复杂对象，由具体建造者来创建其各个零部件。
2. 抽象建造者（Builder）：它是一个包含创建产品各个子部件的抽象方法的接口，通常还包含一个返回复杂产品的方法 getResult()。
3. 具体建造者(Concrete Builder）：实现 Builder 接口，完成复杂产品的各个部件的具体创建方法。
4. 指挥者（Director）：它调用建造者对象中的部件构造与装配方法完成复杂对象的创建，在指挥者中不涉及具体产品的信息。

(1) 产品角色：包含多个组成部件的复杂对象。

class Product {
  private String partA;
  private String partB;
  private String partC;
  public void setPartA(String partA) {
    this.partA = partA;
  }
  public void setPartB(String partB) {
    this.partB = partB;
  }
  public void setPartC(String partC) {
    this.partC = partC;
  }
  public void show() {
    //显示产品的特性
  }
}

(2) 抽象建造者：包含创建产品各个子部件的抽象方法。

abstract class Builder {
  //创建产品对象
  protected Product product = new Product();
  public abstract void buildPartA();
  public abstract void buildPartB();
  public abstract void buildPartC();
  //返回产品对象
  public Product getResult() {
    return product;
  }
}

(3) 具体建造者：实现了抽象建造者接口

public class ConcreteBuilder extends Builder {
  public void buildPartA() {
    product.setPartA("建造 PartA");
  }
  public void buildPartB() {
    product.setPartB("建造 PartB");
  }
  public void buildPartC() {
    product.setPartC("建造 PartC");
  }
}

(4) 指挥者：调用建造者中的方法完成复杂对象的创建。

class Director {
  private Builder builder;
  public Director(Builder builder) {
    this.builder = builder;
  }
  //产品构建与组装方法
  public Product construct() {
    builder.buildPartA();
    builder.buildPartB();
    builder.buildPartC();
    return builder.getResult();
  }
}

(5) 客户类。

public class Client {
  public static void main(String[] args) {
    Builder builder = new ConcreteBuilder(); //生成具体构造者
    Director director = new Director(builder); //生成指挥
    Product product = director.construct(); //指挥构造
    product.show();
  }
}

———- 结构型模式 ———-

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

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

6.代理模式

概述

引入：

• 在有些情况下，一个客户不能或者不想直接访问另一个对象，这时需要找一个中介帮忙完成某项任务，这个中介就是代理对象。例如，购买火车票不一定要去火车站买，可以通过 12306 网站或者去火车票代售点买。又如找女朋友、找保姆、找工作等都可以通过找中介完成。

• 在软件设计中，使用代理模式的例子也很多，例如，要访问的远程对象比较大（如视频或大图像等），其下载要花很多时间。还有因为安全原因需要屏蔽客户端直接访问真实对象，如某单位的内部数据库等。

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

特点：

• 当无法或不想直接引用某个对象或访问某个对象存在困难时，可以通过代理对象来间接访问。使用代理模式主要有两个目的：一是保护目标对象，二是增强目标对象。

优点：

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

缺点：

• 代理模式会造成系统设计中类的数量增加
• 在客户端和目标对象之间增加一个代理对象，会造成请求处理速度变慢；
• 增加了系统的复杂度；

那么如何解决以上提到的缺点呢？答案是可以使用动态代理方式

应用场景：

• 远程代理，这种方式通常是为了隐藏目标对象存在于不同地址空间的事实，方便客户端访问。例如，用户申请某些网盘空间时，会在用户的文件系统中建立一个虚拟的硬盘，用户访问虚拟硬盘时实际访问的是网盘空间。
• 虚拟代理，这种方式通常用于要创建的目标对象开销很大时。例如，下载一幅很大的图像需要很长时间，因某种计算比较复杂而短时间无法完成，这时可以先用小比例的虚拟代理替换真实的对象，消除用户对服务器慢的感觉。
• 安全代理，这种方式通常用于控制不同种类客户对真实对象的访问权限。
• 智能指引，主要用于调用目标对象时，代理附加一些额外的处理功能。例如，增加计算真实对象的引用次数的功能，这样当该对象没有被引用时，就可以自动释放它。
• 延迟加载，指为了提高系统的性能，延迟对目标的加载。例如，Hibernate 中就存在属性的延迟加载和关联表的延时加载。

结构与实现

代理模式的结构比较简单，主要是通过定义一个继承抽象主题的代理来包含真实主题，从而实现对真实主题的访问，下面来分析其基本结构和实现方法。

代理模式的主要角色如下。

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

根据代理的创建时期，代理模式分为静态代理和动态代理。

• 静态：由程序员创建代理类或特定工具自动生成源代码再对其编译，在程序运行前代理类的 .class 文件就已经存在了。
• 动态：在程序运行时，运用反射机制动态创建而成

静态代理

package proxy;
public class ProxyTest {
  public static void main(String[] args) {
    RealSubject realSubject = new ReadSubject();
    Proxy proxy = new Proxy(realSubject);
    proxy.Request();
  }
}
//抽象主题
interface Subject {
  void Request();
}
//真实主题
class RealSubject implements Subject {
  public void Request() {
    System.out.println("访问真实主题方法...");
  }
}
//代理
class Proxy implements Subject {
  private RealSubject realSubject;
  public Proxy(RealSubject realSubject)
  {
		this.realSubject = realSubject;
  }
  public void Request() {
    preRequest();
    realSubject.Request();
    postRequest();
  }
  public void preRequest() {
    System.out.println("访问真实主题之前的预处理。");
  }
  public void postRequest() {
    System.out.println("访问真实主题之后的后续处理。");
  }
}

输出

访问真实主题之前的预处理。
访问真实主题方法...
访问真实主题之后的后续处理。

以上代码做了修改，使其更符合代理模式的思维，结构图就别看了，画得很臭

动态代理

• 动态代理分为两大类：基于接口的动态代理，基于类的动态代理
  • 基于接口：JDK动态代理 [使用]
  • 基于类：cglib

需要了解两个类：Proxy(代理)，InvocationHandler(调用处理程序)

优点：

• 静态代理优点都具备
• 一个动态代理类代理的是一个接口，一般就是对应的一类业务
• 一个动态代理类可以代理多个类，只要实现同一接口即可

租房例子

1）接口

package com.cong.demo02;

//租房
public interface Rent {
  void rent();
  void advocate();
}

2）真实角色

//房东
public class Host implements Rent {
  public void rent() 
  {
    System.out.println("房东要出租房子!");
  }
  public void advocate() 
  { 
    System.out.println("房东推广!");                    
  }
}

3）动态生成代理的角色

package com.cong.demo02;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

/**
 * @PackageName: com.cong.demo02
 * @ClassName: ProxyInvocationHandler
 * @Author: 聪头
 * @Date: 2021/6/16 14:30
 * @Description: 动态生成代理角色的通用类
 */
public class ProxyInvocationHandler implements InvocationHandler {

  //被代理的接口
  private Object target;

  public void setTarget(Object target)
  {
    this.target = target;
  }

  //生成得到代理类
  //    loader - 类加载器来定义代理类
  //    interfaces - 代理类实现的接口列表
  //    h - 调度方法调用的调用处理函数
  //返回值：具有由指定的类加载器定义 并实现指定接口的代理类的 指定调用处理程序的 代理实例
  public Object getProxy()
  {
    return Proxy.newProxyInstance(this.getClass().getClassLoader(),
                                  target.getClass().getInterfaces(), this);
  }

  //官方：每个代理实例都有一个关联的调用处理程序。 当在代理实例上调用方法时，
  // 方法调用将被编码并分派到其调用处理程序的invoke方法。
  //处理代理示例，并返回结果
  @Override
  public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    //调用前的附属方法...

    //动态代理的本质，就是使用反射机制实现
    Object result = method.invoke(target, args);

    //调用后的附属方法...
    return result;
  }
}

4）测试

public static void main(String[] args) {
  //真实角色
  Host host = new Host();
  //代理角色处理程序：现在还没有代理角色
  ProxyInvocationHandler pih = new ProxyInvocationHandler();
  //通过调用程序处理角色 来处理我们要调用的接口对象
  pih.setTarget(host);
  Rent proxy = (Rent) pih.getProxy(); //动态生成的代理角色，代理的是接口
  proxy.rent();
  proxy.advocate();
}

注意点：第8行要使用接口接收，而不能使用实现类

7.适配器模式

概述

引入：

• 在现实生活中，经常出现两个对象因接口不兼容而不能在一起工作的实例，这时需要第三者进行适配。例如，讲中文的人同讲英文的人对话时需要一个翻译，用直流电的笔记本电脑接交流电源时需要一个电源适配器，用计算机访问照相机的 SD 内存卡时需要一个读卡器等。
• 在软件设计中也可能出现：需要开发的具有某种业务功能的组件在现有的组件库中已经存在，但它们与当前系统的接口规范不兼容，如果重新开发这些组件成本又很高，这时用适配器模式能很好地解决这些问题。

定义：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。适配器模式分为类结构型模式和对象结构型模式两种，前者类之间的耦合度比后者高，且要求程序员了解现有组件库中的相关组件的内部结构，所以应用相对较少些。

优点：

• 客户端通过适配器可以透明地调用目标接口。
• 复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类。
• 将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题。
• 在很多业务场景中符合开闭原则。

缺点：

• 适配器编写过程需要结合业务场景全面考虑，可能会增加系统的复杂性。
• 增加代码阅读难度，降低代码可读性，过多使用适配器会使系统代码变得凌乱。

应用场景：

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

扩展：

• 适配器模式（Adapter）可扩展为双向适配器模式，双向适配器类既可以把适配者接口转换成目标接口，也可以把目标接口转换成适配者接口

结构与实现

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

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

类适配器：适配器通过继承来访问适配者

对象适配器：适配器通过组合来访问适配者

类适配器

package adapter;
//目标接口
interface Target
{
  public void request();
}
//适配者接口
class Adaptee
{
  public void specificRequest()
  {       
    System.out.println("适配者中的业务代码被调用！");
  }
}
//类适配器类
class ClassAdapter extends Adaptee implements Target
{
  public void request()
  {
    specificRequest();
  }
}
//客户端代码
public class ClassAdapterTest
{
  public static void main(String[] args)
  {
    System.out.println("类适配器模式测试：");
    Target target = new ClassAdapter();
    target.request();
  }
}

输出

类适配器模式测试：
适配者中的业务代码被调用！

结构适配器

package adapter;
//对象适配器类
class ObjectAdapter implements Target
{
  private Adaptee adaptee;
  public ObjectAdapter(Adaptee adaptee)
  {
    this.adaptee=adaptee;
  }
  public void request()
  {
    adaptee.specificRequest();
  }
}
//客户端代码
public class ObjectAdapterTest
{
  public static void main(String[] args)
  {
    System.out.println("对象适配器模式测试：");
    Adaptee adaptee = new Adaptee();
    Target target = new ObjectAdapter(adaptee);
    target.request();
  }
}

输出

对象适配器模式测试：
适配者中的业务代码被调用！

8.桥接模式 ☆

概述

引入：

• 在现实生活中，某些类具有两个或多个维度的变化，如图形既可按形状分，又可按颜色分。如何设计类似于 Photoshop 这样的软件，能画不同形状和不同颜色的图形呢？如果用继承方式，m 种形状和 n 种颜色的图形就有 m×n 种，不但对应的子类很多，而且扩展困难。
• 当然，这样的例子还有很多，如不同颜色和字体的文字、不同品牌和功率的汽车、不同性别和职业的男女、支持不同平台和不同文件格式的媒体播放器等。如果用桥接模式就能很好地解决这些问题。

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

优点：

• 抽象与实现分离，扩展能力强
• 符合开闭原则
• 符合合成复用原则
• 其实现细节对客户透明

缺点：

• 由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，能正确地识别出系统中两个独立变化的维度，这增加了系统的理解与设计难度。

应用场景：

当一个类内部具备两种或多种变化维度时，使用桥接模式可以解耦这些变化的维度，使高层代码架构稳定。

1. 当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时。
2. 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
3. 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。

桥接模式的一个常见使用场景就是替换继承。我们知道，继承拥有很多优点，比如，抽象、封装、多态等，父类封装共性，子类实现特性。继承可以很好的实现代码复用（封装）的功能，但这也是继承的一大缺点。

因为父类拥有的方法，子类也会继承得到，无论子类需不需要，这说明继承具备强侵入性（父类代码侵入子类），同时会导致子类臃肿。因此，在设计模式中，有一个原则为优先使用组合/聚合，而不是继承。

扩展：

在软件开发中，有时桥接（Bridge）模式可与适配器模式联合使用。当桥接（Bridge）模式的实现化角色的接口与现有类的接口不一致时，可以在二者中间定义一个适配器将二者连接起来

结构与实现

可以将抽象化部分与实现化部分分开，取消二者的继承关系，改用组合关系。

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

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

package bridge;
public class BridgeTest {
  public static void main(String[] args) {
    Implementor imple = new ConcreteImplementorA(); //具体实现化角色
    Abstraction abs = new RefinedAbstraction(imple); //扩展抽象化角色
    //在扩展父类Operation方法的同时，能够访问实现化角色提供的方法
    //相当于更细粒度的继承，本质上用组合代替继承，能够节省开销
    abs.Operation();
  }
}
//实现化角色
interface Implementor {
  public void OperationImpl();
}
//具体实现化角色
class ConcreteImplementorA implements Implementor {
  public void OperationImpl() {
    System.out.println("具体实现化(Concrete Implementor)角色被访问");
  }
}
//抽象化角色
abstract class Abstraction {
  protected Implementor imple;
  protected Abstraction(Implementor imple) {
    this.imple = imple;
  }
  public abstract void Operation();
}
//扩展抽象化角色
class RefinedAbstraction extends Abstraction {
  public RefinedAbstraction(Implementor imple) {
    super(imple);
  }
  public void Operation() {
    System.out.println("扩展抽象化(Refined Abstraction)角色被访问");
    imple.OperationImpl();
  }
}

输出

扩展抽象化(Refined Abstraction)角色被访问
具体实现化(Concrete Implementor)角色被访问

9.装饰器模式

概述

引入：

• 上班族大多都有睡懒觉的习惯，每天早上上班时间都很紧张，于是很多人为了多睡一会，就会用方便的方式解决早餐问题。有些人早餐可能会吃煎饼，煎饼中可以加鸡蛋，也可以加香肠，但是不管怎么“加码”，都还是一个煎饼。在现实生活中，常常需要对现有产品增加新的功能或美化其外观，如房子装修、相片加相框等，都是装饰器模式。
• 在软件开发过程中，有时想用一些现存的组件。这些组件可能只是完成了一些核心功能。但在不改变其结构的情况下，可以动态地扩展其功能。所有这些都可以釆用装饰器模式来实现。

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

优点：

• 装饰器是继承的有力补充，比继承灵活，在不改变原有对象的情况下，动态的给一个对象扩展功能，即插即用
• 通过使用不用装饰类及这些装饰类的排列组合，可以实现不同效果
• 装饰器模式完全遵守开闭原则

缺点：装饰器模式会增加许多子类，过度使用会增加程序得复杂性。

应用场景：

• 当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。例如，该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
• 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰器模式却很好实现。
• 当对象的功能要求可以动态地添加，也可以再动态地撤销时。

扩展：装饰器模式所包含的 4 个角色不是任何时候都要存在的，在有些应用环境下模式是可以简化的，如以下两种情况。

• 如果只有一个具体构件而没有抽象构件时，可以让抽象装饰继承具体构件

• 如果只有一个具体装饰时，可以将抽象装饰和具体装饰合并

结构与实现

通常情况下，扩展一个类的功能会使用继承方式来实现。但继承具有静态特征，耦合度高，并且随着扩展功能的增多，子类会很膨胀。如果使用组合关系来创建一个包装对象（即装饰对象）来包裹真实对象，并在保持真实对象的类结构不变的前提下，为其提供额外的功能，这就是装饰器模式的目标。下面来分析其基本结构和实现方法。

装饰器模式主要包含以下角色。

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

package decorator;
public class DecoratorPattern {
  public static void main(String[] args) {
    Component p = new ConcreteComponent();
    p.operation();
    System.out.println("---------------------------------");
    Component d = new ConcreteDecorator(p);
    d.operation();
  }
}
//抽象构件角色
interface Component {
  public void operation();
}
//具体构件角色
class ConcreteComponent implements Component {
  public ConcreteComponent() {
    System.out.println("创建具体构件角色");
  }
  public void operation() {
    System.out.println("调用具体构件角色的方法operation()");
  }
}
//抽象装饰角色
class Decorator implements Component {
  private Component component;
  public Decorator(Component component) {
    this.component = component;
  }
  public void operation() {
    component.operation();
  }
}
//具体装饰角色
class ConcreteDecorator extends Decorator {
  public ConcreteDecorator(Component component) {
    super(component);
  }
  public void operation() {
    super.operation();
    addedFunction();
  }
  public void addedFunction() {
    System.out.println("为具体构件角色增加额外的功能addedFunction()");
  }
}

输出

创建具体构件角色
调用具体构件角色的方法operation()
---------------------------------
调用具体构件角色的方法operation()
为具体构件角色增加额外的功能addedFunction()

10.外观模式 ☆

概述

引入：

• 在现实生活中，常常存在办事较复杂的例子，如办房产证或注册一家公司，有时要同多个部门联系，这时要是有一个综合部门能解决一切手续问题就好了。
• 软件设计也是这样，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟着改变，这违背了“开闭原则”，也违背了“迪米特法则”，所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度，这就是外观模式的目标。

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

在日常编码工作中，我们都在有意无意的大量使用外观模式。只要是高层模块需要调度多个子系统（2个以上的类对象），我们都会自觉地创建一个新的类封装这些子系统，提供精简的接口，让高层模块可以更加容易地间接调用这些子系统的功能。尤其是现阶段各种第三方SDK、开源类库，很大概率都会使用外观模式。

优点：外观（Facade）模式是“迪米特法则”的典型应用

1. 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
2. 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
3. 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。

缺点：

1. 不能很好地限制客户使用子系统类，很容易带来未知风险。
2. 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

应用场景：

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

扩展：在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题

结构与实现

外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。

外观（Facade）模式包含以下主要角色。

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

package facade;
public class FacadePattern {
  public static void main(String[] args) {
    Facade f = new Facade();
    f.method();
  }
}
//外观角色
class Facade {
  private SubSystem01 obj1 = new SubSystem01();
  private SubSystem02 obj2 = new SubSystem02();
  private SubSystem03 obj3 = new SubSystem03();
  public void method() {
    obj1.method1();
    obj2.method2();
    obj3.method3();
  }
}
//子系统角色
class SubSystem01 {
  public void method1() {
    System.out.println("子系统01的method1()被调用！");
  }
}
//子系统角色
class SubSystem02 {
  public void method2() {
    System.out.println("子系统02的method2()被调用！");
  }
}
//子系统角色
class SubSystem03 {
  public void method3() {
    System.out.println("子系统03的method3()被调用！");
  }
}

11.享元模式 ☆

概述

引入：

• 在面向对象程序设计过程中，有时会面临要创建大量相同或相似对象实例的问题。创建那么多的对象将会耗费很多的系统资源，它是系统性能提高的一个瓶颈。
• 例如，围棋和五子棋中的黑白棋子，图像中的坐标点或颜色，局域网中的路由器、交换机和集线器，教室里的桌子和凳子等。这些对象有很多相似的地方，如果能把它们相同的部分提取出来共享，则能节省大量的系统资源，这就是享元模式的产生背景。

定义：

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

优点：

• 相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。

缺点：

1. 为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。
2. 读取享元模式的外部状态会使得运行时间稍微变长。

应用场景：

1. 系统中存在大量相同或相似的对象，这些对象耗费大量的内存资源。
2. 大部分的对象可以按照内部状态进行分组，且可将不同部分外部化，这样每一个组只需保存一个内部状态。
3. 由于享元模式需要额外维护一个保存享元的数据结构，所以应当在有足够多的享元实例时才值得使用享元模式。

结构与实现

享元模式的定义提出了两个要求，细粒度和共享对象。我们将这些对象的信息分为两个部分：内部状态和外部状态。

• 内部状态指对象共享出来的信息，存储在享元信息内部，并且不会随环境的改变而改变；
• 外部状态指对象得以依赖的一个标记，随环境的改变而改变，不可共享。

享元模式的本质是缓存共享对象，降低内存消耗。

享元模式的主要角色有如下。

1. 抽象享元角色（Flyweight）：是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入。
2. 具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口。
3. 非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中。
4. 享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。

public class FlyweightPattern {
  public static void main(String[] args) {
    FlyweightFactory factory = new FlyweightFactory();
    Flyweight f01 = factory.getFlyweight("a");
    Flyweight f02 = factory.getFlyweight("a");
    Flyweight f03 = factory.getFlyweight("a");
    Flyweight f11 = factory.getFlyweight("b");
    Flyweight f12 = factory.getFlyweight("b");
    f01.operation(new UnsharedConcreteFlyweight("第1次调用a。"));
    f02.operation(new UnsharedConcreteFlyweight("第2次调用a。"));
    f03.operation(new UnsharedConcreteFlyweight("第3次调用a。"));
    f11.operation(new UnsharedConcreteFlyweight("第1次调用b。"));
    f12.operation(new UnsharedConcreteFlyweight("第2次调用b。"));
  }
}
//非享元角色
class UnsharedConcreteFlyweight {
  private String info;
  public UnsharedConcreteFlyweight(String info) {
    this.info = info;
  }
  public String getInfo() {
    return info;
  }
  public void setInfo(String info) {
    this.info = info;
  }
}
//抽象享元角色
interface Flyweight {
  public void operation(UnsharedConcreteFlyweight state);
}
//具体享元角色
class ConcreteFlyweight implements Flyweight {
  private String key;
  public ConcreteFlyweight(String key) {
    this.key = key;
    System.out.println("具体享元" + key + "被创建！");
  }
  public void operation(UnsharedConcreteFlyweight outState) {
    System.out.print("具体享元" + key + "被调用，");
    System.out.println("非享元信息是:" + outState.getInfo());
  }
}
//享元工厂角色
class FlyweightFactory {
  private HashMap<String, Flyweight> flyweights = new HashMap<String, Flyweight>();
  public Flyweight getFlyweight(String key) {
    Flyweight flyweight = (Flyweight) flyweights.get(key);
    if (flyweight != null) {
      System.out.println("具体享元" + key + "已经存在，被成功获取！");
    } else {
      flyweight = new ConcreteFlyweight(key);
      flyweights.put(key, flyweight);
    }
    return flyweight;
  }
}

具体享元a被创建！
具体享元a已经存在，被成功获取！
具体享元a已经存在，被成功获取！
具体享元b被创建！
具体享元b已经存在，被成功获取！
具体享元a被调用，非享元信息是:第1次调用a。
具体享元a被调用，非享元信息是:第2次调用a。
具体享元a被调用，非享元信息是:第3次调用a。
具体享元b被调用，非享元信息是:第1次调用b。
具体享元b被调用，非享元信息是:第2次调用b。

例子举的很臭，因为从头到尾只有a，b两个具体享元对象。享元模式说的是大量对象的创建，本例中根本没有体现“大量”二字！

12.组合模式

概述

引入：在现实生活中，存在很多“部分-整体”的关系，例如，大学中的部门与学院、总公司中的部门与分公司、学习用品中的书与书包、生活用品中的衣服与衣柜、以及厨房中的锅碗瓢盆等。在软件开发中也是这样，例如，文件系统中的文件与文件夹、窗体程序中的简单控件与容器控件等。对这些简单对象与复合对象的处理，如果用组合模式来实现会很方便。

定义：有时又叫作整体-部分（Part-Whole）模式，它是一种将对象组合成树状的层次结构的模式，用来表示“整体-部分”的关系，使用户对单个对象和组合对象具有一致的访问性，属于结构型设计模式。

• 组合模式一般用来描述整体与部分的关系，它将对象组织到树形结构中，顶层的节点被称为根节点，根节点下面可以包含树枝节点和叶子节点，树枝节点下面又可以包含树枝节点和叶子节点，树形结构图如下。

• 由上图可以看出，其实根节点和树枝节点本质上属于同一种数据类型，可以作为容器使用；而叶子节点与树枝节点在语义上不属于用一种类型。但是在组合模式中，会把树枝节点和叶子节点看作属于同一种数据类型（用统一接口定义），让它们具备一致行为。

• 这样，在组合模式中，整个树形结构中的对象都属于同一种类型，带来的好处就是用户不需要辨别是树枝节点还是叶子节点，可以直接进行操作，给用户的使用带来极大的便利。

优点：

1. 组合模式使得客户端代码可以一致地处理单个对象和组合对象，无须关心自己处理的是单个对象，还是组合对象，这简化了客户端代码；
2. 更容易在组合体内加入新的对象，客户端不会因为加入了新的对象而更改源代码，满足“开闭原则”；

缺点：

1. 设计较复杂，客户端需要花更多时间理清类之间的层次关系；
2. 不容易限制容器中的构件；
3. 不容易用继承的方法来增加构件的新功能；

应用场景：

1. 在需要表示一个对象整体与部分的层次结构的场合。
2. 要求对用户隐藏组合对象与单个对象的不同，用户可以用统一的接口使用组合结构中的所有对象的场合。

结构与实现

组合模式包含以下主要角色。

1. 抽象构件（Component）角色：它的主要作用是为树叶构件和树枝构件声明公共接口，并实现它们的默认行为。在透明式的组合模式中抽象构件还声明访问和管理子类的接口；在安全式的组合模式中不声明访问和管理子类的接口，管理工作由树枝构件完成。（总的抽象类或接口，定义一些通用的方法，比如新增、删除）
2. 树叶构件（Leaf）角色：是组合中的叶节点对象，它没有子节点，用于继承或实现抽象构件。
3. 树枝构件（Composite）角色 / 中间构件：是组合中的分支节点对象，它有子节点，用于继承和实现抽象构件。它的主要作用是存储和管理子部件，通常包含 Add()、Remove()、GetChild() 等方法。

假如要访问集合 c0={leaf1,{leaf2,leaf3}} 中的元素，其对应的树状图如图 3 所示。

(1) 透明方式

在该方式中，由于抽象构件声明了所有子类中的全部方法，所以客户端无须区别树叶对象和树枝对象，对客户端来说是透明的。但其缺点是：树叶构件本来没有 Add()、Remove() 及 GetChild() 方法，却要实现它们（空实现或抛异常），这样会带来一些安全性问题。

public class CompositePattern {
  public static void main(String[] args) {
    Component c0 = new Composite();
    Component c1 = new Composite();
    Component leaf1 = new Leaf("1");
    Component leaf2 = new Leaf("2");
    Component leaf3 = new Leaf("3");
    c0.add(leaf1);
    c0.add(c1);
    c1.add(leaf2);
    c1.add(leaf3);
    c0.operation();
  }
}
//抽象构件
interface Component {
  public void add(Component c);
  public void remove(Component c);
  public Component getChild(int i);
  public void operation();
}
//树叶构件
class Leaf implements Component {
  private String name;
  public Leaf(String name) {
    this.name = name;
  }
  public void add(Component c) {
  }
  public void remove(Component c) {
  }
  public Component getChild(int i) {
    return null;
  }
  public void operation() {
    System.out.println("树叶" + name + "：被访问！");
  }
}
//树枝构件
class Composite implements Component {
  private ArrayList<Component> children = new ArrayList<Component>();
  public void add(Component c) {
    children.add(c);
  }
  public void remove(Component c) {
    children.remove(c);
  }
  public Component getChild(int i) {
    return children.get(i);
  }
  public void operation() {
    for (Object obj : children) {
      ((Component) obj).operation();
    }
  }
}

输出

树叶1：被访问！
树叶2：被访问！
树叶3：被访问！

(2) 安全方式

在该方式中，将管理子构件的方法移到树枝构件中，抽象构件和树叶构件没有对子对象的管理方法，这样就避免了上一种方式的安全性问题，但由于叶子和分支有不同的接口，客户端在调用时要知道树叶对象和树枝对象的存在，所以失去了透明性。

首先修改 Component 代码，只保留层次的公共行为。

interface Component {
    public void operation();
}

然后修改客户端代码，将树枝构件类型更改为 Composite 类型，以便获取管理子类操作的方法。

public class CompositePattern {
  public static void main(String[] args) {
    Composite c0 = new Composite();
    Composite c1 = new Composite();
    Component leaf1 = new Leaf("1");
    Component leaf2 = new Leaf("2");
    Component leaf3 = new Leaf("3");
    c0.add(leaf1);
    c0.add(c1);
    c1.add(leaf2);
    c1.add(leaf3);
    c0.operation();
  }
}

———- 行为型模式 ———-

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

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

13.模板方法模式

概述

引入：

• 在面向对象程序设计过程中，程序员常常会遇到这种情况：设计一个系统时知道了算法所需的关键步骤，而且确定了这些步骤的执行顺序，但某些步骤的具体实现还未知，或者说某些步骤的实现与具体的环境相关。
• 例如，一个人每天会起床、吃饭、做事、睡觉等，其中“做事”的内容每天可能不同。我们把这些规定了流程或格式的实例定义成模板，允许使用者根据自己的需求去更新它，例如，简历模板、论文模板、Word 中模板文件等。
• 以下介绍的模板方法模式将解决以上类似的问题。

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

优点：

1. 它封装了不变部分，扩展可变部分。它把认为是不变部分的算法封装到父类中实现，而把可变部分算法由子类继承实现，便于子类继续扩展。
2. 它在父类中提取了公共的部分代码，便于代码复用。
3. 部分方法是由子类实现的，因此子类可以通过扩展方式增加相应的功能，符合开闭原则。

缺点：

1. 对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象，间接地增加了系统实现的复杂度。
2. 父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度。
3. 由于继承关系自身的缺点，如果父类添加新的抽象方法，则所有子类都要改一遍。

应用场景：

1. 算法的整体步骤很固定，但其中个别部分易变时，这时候可以使用模板方法模式，将容易变的部分抽象出来，供子类实现。
2. 当多个子类存在公共的行为时，可以将其提取出来并集中到一个公共父类中以避免代码重复。首先，要识别现有代码中的不同之处，并且将不同之处分离为新的操作。最后，用一个调用这些新的操作的模板方法来替换这些不同的代码。
3. 当需要控制子类的扩展时，模板方法只在特定点调用钩子操作，这样就只允许在这些点进行扩展。

结构与实现

模板方法模式需要注意抽象类与具体子类之间的协作。它用到了虚函数的多态性技术以及“不用调用我，让我来调用你”的反向控制技术。现在来介绍它们的基本结构。

模板方法模式包含以下主要角色。

1）抽象类/抽象模板（Abstract Class）

抽象模板类，负责给出一个算法的轮廓和骨架。它由一个模板方法和若干个基本方法构成。这些方法的定义如下。

① 模板方法：定义了算法的骨架，按某种顺序调用其包含的基本方法。

② 基本方法：是整个算法中的一个步骤，包含以下几种类型。

• 抽象方法：在抽象类中声明，由具体子类实现。
• 具体方法：在抽象类中已经实现，在具体子类中可以继承或重写它。
• 钩子方法：在抽象类中已经实现，包括用于判断的逻辑方法和需要子类重写的空方法两种。

2）具体子类/具体实现（Concrete Class）

具体实现类，实现抽象类中所定义的抽象方法和钩子方法，它们是一个顶级逻辑的一个组成步骤。

public class TemplateMethodPattern {
  public static void main(String[] args) {
    AbstractClass tm = new ConcreteClass();
    tm.TemplateMethod();
  }
}
//抽象类
abstract class AbstractClass {
  //模板方法
  public void TemplateMethod() {
    SpecificMethod();
    abstractMethod1();
    abstractMethod2();
  }
  //具体方法
  public void SpecificMethod() {
    System.out.println("抽象类中的具体方法被调用...");
  }
  //抽象方法1
  public abstract void abstractMethod1();
  //抽象方法2
  public abstract void abstractMethod2();
}
//具体子类
class ConcreteClass extends AbstractClass {
  public void abstractMethod1() {
    System.out.println("抽象方法1的实现被调用...");
  }
  public void abstractMethod2() {
    System.out.println("抽象方法2的实现被调用...");
  }
}

输出

抽象类中的具体方法被调用...
抽象方法1的实现被调用...
抽象方法2的实现被调用...

扩展：钩子函数

在模板方法模式中，基本方法包含：抽象方法、具体方法和钩子方法，正确使用“钩子方法”可以使得子类控制父类的行为。如下面例子中，可以通过在具体子类中重写钩子方法 HookMethod1() 和 HookMethod2() 来改变抽象父类中的运行结果，其结构图如图 3 所示。

public class HookTemplateMethod {
  public static void main(String[] args) {
    HookAbstractClass tm = new HookConcreteClass();
    tm.TemplateMethod();
  }
}
//含钩子方法的抽象类
abstract class HookAbstractClass {
  //模板方法
  public void TemplateMethod() {
    abstractMethod1();
    HookMethod1();
    if (HookMethod2()) {
      SpecificMethod();
    }
    abstractMethod2();
  }
  //具体方法
  public void SpecificMethod() {
    System.out.println("抽象类中的具体方法被调用...");
  }
  //钩子方法1
  public void HookMethod1() {
  }
  //钩子方法2
  public boolean HookMethod2() {
    return true;
  }
  //抽象方法1
  public abstract void abstractMethod1();
  //抽象方法2
  public abstract void abstractMethod2();
}
//含钩子方法的具体子类
class HookConcreteClass extends HookAbstractClass {
  public void abstractMethod1() {
    System.out.println("抽象方法1的实现被调用...");
  }
  public void abstractMethod2() {
    System.out.println("抽象方法2的实现被调用...");
  }
  public void HookMethod1() {
    System.out.println("钩子方法1被重写...");
  }
  public boolean HookMethod2() {
    return false;
  }
}

输出

抽象方法1的实现被调用...
钩子方法1被重写...
抽象方法2的实现被调用...

如果钩子方法 HookMethod1() 和钩子方法 HookMethod2() 的代码改变，则程序的运行结果也会改变

14.策略模式 ☆

概述

引入：

• 在现实生活中常常遇到实现某种目标存在多种策略可供选择的情况，例如，出行旅游可以乘坐飞机、乘坐火车、骑自行车或自己开私家车等，超市促销可以釆用打折、送商品、送积分等方法。
• 在软件开发中也常常遇到类似的情况，当实现某一个功能存在多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能，如数据排序策略有冒泡排序、选择排序、插入排序、二叉树排序等。
• 如果使用多重条件转移语句实现（即硬编码），不但使条件语句变得很复杂，而且增加、删除或更换算法要修改原代码，不易维护，违背开闭原则。如果采用策略模式就能很好解决该问题。

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

优点：

1. 多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句，如 if…else 语句、switch…case 语句。
2. 策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。
3. 策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。
4. 策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。
5. 策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。

缺点：

1. 客户端必须理解所有策略算法的区别，以便适时选择恰当的算法类。
2. 策略模式造成很多的策略类，增加维护难度。

应用场景：

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

扩展：在一个使用策略模式的系统中，当存在的策略很多时，客户端管理所有策略算法将变得很复杂，如果在环境类中使用策略工厂模式来管理这些策略类将大大减少客户端的工作复杂度，其结构图如图 5 所示。

结构与实现

策略模式是准备一组算法，并将这组算法封装到一系列的策略类里面，作为一个抽象策略类的子类。策略模式的重心不是如何实现算法，而是如何组织这些算法，从而让程序结构更加灵活，具有更好的维护性和扩展性，现在我们来分析其基本结构和实现方法。

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

1. 抽象策略（Strategy）类：定义了一个公共接口，各种不同的算法以不同的方式实现这个接口，环境角色使用这个接口调用不同的算法，一般使用接口或抽象类实现。
2. 具体策略（Concrete Strategy）类：实现了抽象策略定义的接口，提供具体的算法实现。
3. 环境（Context）类：持有一个策略类的引用，最终给客户端调用。

public class StrategyPattern {
  public static void main(String[] args) {
    Context c = new Context();
    Strategy s = new ConcreteStrategyA();
    c.setStrategy(s);
    c.strategyMethod();
    System.out.println("-----------------");
    s = new ConcreteStrategyB();
    c.setStrategy(s);
    c.strategyMethod();
  }
}
//抽象策略类
interface Strategy {
  public void strategyMethod();    //策略方法
}
//具体策略类A
class ConcreteStrategyA implements Strategy {
  public void strategyMethod() {
    System.out.println("具体策略A的策略方法被访问！");
  }
}
//具体策略类B
class ConcreteStrategyB implements Strategy {
  public void strategyMethod() {
    System.out.println("具体策略B的策略方法被访问！");
  }
}
//环境类
class Context {
  private Strategy strategy;
  public Strategy getStrategy() {
    return strategy;
  }
  public void setStrategy(Strategy strategy) {
    this.strategy = strategy;
  }
  public void strategyMethod() {
    strategy.strategyMethod();
  }
}

输出

具体策略A的策略方法被访问！
-----------------
具体策略B的策略方法被访问！

15.命令模式 ☆

概述

引入：

• 在软件开发系统中，“方法的请求者”与“方法的实现者”之间经常存在紧密的耦合关系，这不利于软件功能的扩展与维护。例如，想对方法进行“撤销、重做、记录”等处理都很不方便，因此“如何将方法的请求者与实现者解耦？”变得很重要，命令模式就能很好地解决这个问题。
• 在现实生活中，命令模式的例子也很多。比如看电视时，我们只需要轻轻一按遥控器就能完成频道的切换，这就是命令模式，将换台请求和换台处理完全解耦了。电视机遥控器（命令发送者）通过按钮（具体命令）来遥控电视机（命令接收者）。
• 再比如，我们去餐厅吃饭，菜单不是等到客人来了之后才定制的，而是已经预先配置好的。这样，客人来了就只需要点菜，而不是任由客人临时定制。餐厅提供的菜单就相当于把请求和处理进行了解耦，这就是命令模式的体现。

定义：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。这样两者之间通过命令对象进行沟通，这样方便将命令对象进行储存、传递、调用、增加与管理。

优点：

1. 通过引入中间件（抽象接口）降低系统的耦合度。
2. 扩展性良好，增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，且满足“开闭原则”。
3. 可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
4. 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。
5. 可以在现有命令的基础上，增加额外功能。比如日志记录，结合装饰器模式会更加灵活。

缺点：

1. 可能产生大量具体的命令类。因为每一个具体操作都需要设计一个具体命令类，这会增加系统的复杂性。
2. 命令模式的结果其实就是接收方的执行结果，但是为了以命令的形式进行架构、解耦请求与实现，引入了额外类型结构（引入了请求方与抽象命令接口），增加了理解上的困难。不过这也是设计模式的通病，抽象必然会额外增加类的数量，代码抽离肯定比代码聚合更加难理解。

应用场景：

当系统的某项操作具备命令语义，且命令实现不稳定（变化）时，可以通过命令模式解耦请求与实现。使用抽象命令接口使请求方的代码架构稳定，封装接收方具体命令的实现细节。接收方与抽象命令呈现弱耦合（内部方法无需一致），具备良好的扩展性。

1. 请求调用者需要与请求接收者解耦时，命令模式可以使调用者和接收者不直接交互。
2. 系统随机请求命令或经常增加、删除命令时，命令模式可以方便地实现这些功能。
3. 当系统需要执行一组操作时，命令模式可以定义宏命令来实现该功能。
4. 当系统需要支持命令的撤销（Undo）操作和恢复（Redo）操作时，可以将命令对象存储起来，采用备忘录模式来实现。

结构与实现

可以将系统中的相关操作抽象成命令，使调用者与实现者相关分离，其结构如下。

命令模式包含以下主要角色。

1. 抽象命令类（Command）角色：声明执行命令的接口，拥有执行命令的抽象方法 execute()。
2. 具体命令类（Concrete Command）角色：是抽象命令类的具体实现类，它拥有接收者对象，并通过调用接收者的功能来完成命令要执行的操作。
3. 实现者/接收者（Receiver）角色：执行命令功能的相关操作，是具体命令对象业务的真正实现者。
4. 调用者/请求者（Invoker）角色：是请求的发送者，它通常拥有很多的命令对象，并通过访问命令对象来执行相关请求，它不直接访问接收者。

package command;
public class CommandPattern {
  public static void main(String[] args) {
    Command cmd = new ConcreteCommand();
    Invoker ir = new Invoker(cmd);
    System.out.println("客户访问调用者的call()方法...");
    ir.call();
  }
}
//调用者
class Invoker {
  private Command command;
  public Invoker(Command command) {
    this.command = command;
  }
  public void setCommand(Command command) {
    this.command = command;
  }
  public void call() {
    System.out.println("调用者执行命令command...");
    command.execute();
  }
}
//抽象命令
interface Command {
  public abstract void execute();
}
//具体命令
class ConcreteCommand implements Command {
  private Receiver receiver;
  ConcreteCommand() {
    receiver = new Receiver();
  }
  public void execute() {
    receiver.action();
  }
}
//接收者
class Receiver {
  public void action() {
    System.out.println("接收者的action()方法被调用...");
  }
}

输出：

客户访问调用者的call()方法...
调用者执行命令command...
接收者的action()方法被调用...

扩展：宏命令

在软件开发中，有时将命令模式与前面学的组合模式联合使用，这就构成了宏命令模式，也叫组合命令模式。宏命令包含了一组命令，它充当了具体命令与调用者的双重角色，执行它时将递归调用它所包含的所有命令，其具体结构图如图 3 所示。

package command;
import java.util.ArrayList;
public class CompositeCommandPattern {
  public static void main(String[] args) {
    AbstractCommand cmd1 = new ConcreteCommand1();
    AbstractCommand cmd2 = new ConcreteCommand2();
    CompositeInvoker ir = new CompositeInvoker();
    ir.add(cmd1);
    ir.add(cmd2);
    System.out.println("客户访问调用者的execute()方法...");
    ir.execute();
  }
}
//抽象命令
interface AbstractCommand {
  public abstract void execute();
}
//树叶构件: 具体命令1
class ConcreteCommand1 implements AbstractCommand {
  private CompositeReceiver receiver;
  ConcreteCommand1() {
    receiver = new CompositeReceiver();
  }
  public void execute() {
    receiver.action1();
  }
}
//树叶构件: 具体命令2
class ConcreteCommand2 implements AbstractCommand {
  private CompositeReceiver receiver;
  ConcreteCommand2() {
    receiver = new CompositeReceiver();
  }
  public void execute() {
    receiver.action2();
  }
}
//树枝构件: 调用者
class CompositeInvoker implements AbstractCommand {
  private ArrayList<AbstractCommand> children = new ArrayList<AbstractCommand>();
  public void add(AbstractCommand c) {
    children.add(c);
  }
  public void remove(AbstractCommand c) {
    children.remove(c);
  }
  public AbstractCommand getChild(int i) {
    return children.get(i);
  }
  public void execute() {
    for (Object obj : children) {
      ((AbstractCommand) obj).execute();
    }
  }
}
//接收者
class CompositeReceiver {
  public void action1() {
    System.out.println("接收者的action1()方法被调用...");
  }
  public void action2() {
    System.out.println("接收者的action2()方法被调用...");
  }
}

输出：

客户访问调用者的execute()方法...
接收者的action1()方法被调用...
接收者的action2()方法被调用...

当然，命令模式还可以同备忘录（Memento）模式组合使用，这样就变成了可撤销的命令模式，这将在后面介绍。

16.责任链模式

概述

引入：

• 在现实生活中，一个事件需要经过多个对象处理是很常见的场景。例如，采购审批流程、请假流程等。公司员工请假，可批假的领导有部门负责人、副总经理、总经理等，但每个领导能批准的天数不同，员工必须根据需要请假的天数去找不同的领导签名，也就是说员工必须记住每个领导的姓名、电话和地址等信息，这无疑增加了难度。
• 在计算机软硬件中也有相关例子，如总线网中数据报传送，每台计算机根据目标地址是否同自己的地址相同来决定是否接收；还有异常处理中，处理程序根据异常的类型决定自己是否处理该异常；还有 Struts2 的拦截器、JSP 和 Servlet 的 Filter 等，所有这些，都可以考虑使用责任链模式来实现。

定义：为了避免请求发送者与多个请求处理者耦合在一起，于是将所有请求的处理者通过前一对象记住其下一个对象的引用而连成一条链；当有请求发生时，可将请求沿着这条链传递，直到有对象处理它为止。

• 通俗来讲：在责任链模式中，客户只需要将请求发送到责任链上即可，无须关心请求的处理细节和请求的传递过程，请求会自动进行传递。所以责任链将请求的发送者和请求的处理者解耦了。

注意：责任链模式也叫职责链模式。

优点：

1. 降低了对象之间的耦合度。该模式使得一个对象无须知道到底是哪一个对象处理其请求以及链的结构，发送者和接收者也无须拥有对方的明确信息。
2. 增强了系统的可扩展性。可以根据需要增加新的请求处理类，满足开闭原则。
3. 增强了给对象指派职责的灵活性。当工作流程发生变化，可以动态地改变链内的成员或者调动它们的次序，也可动态地新增或者删除责任。
4. 责任链简化了对象之间的连接。每个对象只需保持一个指向其后继者的引用，不需保持其他所有处理者的引用，这避免了使用众多的 if 或者 if···else 语句。
5. 责任分担。每个类只需要处理自己该处理的工作，不该处理的传递给下一个对象完成，明确各类的责任范围，符合类的单一职责原则。

缺点：

1. 不能保证每个请求一定被处理。由于一个请求没有明确的接收者，所以不能保证它一定会被处理，该请求可能一直传到链的末端都得不到处理。
2. 对比较长的职责链，请求的处理可能涉及多个处理对象，系统性能将受到一定影响。
3. 职责链建立的合理性要靠客户端来保证，增加了客户端的复杂性，可能会由于职责链的错误设置而导致系统出错，如可能会造成循环调用。

应用场景：

1. 多个对象可以处理一个请求，但具体由哪个对象处理该请求在运行时自动确定。
2. 可动态指定一组对象处理请求，或添加新的处理者。
3. 需要在不明确指定请求处理者的情况下，向多个处理者中的一个提交请求。

扩展：

1. 纯的职责链模式：一个请求必须被某一个处理者对象所接收，且一个具体处理者对某个请求的处理只能采用以下两种行为之一：自己处理（承担责任）；把责任推给下家处理。
2. 不纯的职责链模式：允许出现某一个具体处理者对象在承担了请求的一部分责任后又将剩余的责任传给下家的情况，且一个请求可以最终不被任何接收端对象所接收。

结构与实现

职责链模式主要包含以下角色。

1. 抽象处理者（Handler）角色：定义一个处理请求的接口，包含抽象处理方法和一个后继连接。
2. 具体处理者（Concrete Handler）角色：实现抽象处理者的处理方法，判断能否处理本次请求，如果可以处理请求则处理，否则将该请求转给它的后继者。
3. 客户类（Client）角色：创建处理链，并向链头的具体处理者对象提交请求，它不关心处理细节和请求的传递过程。

责任链模式的本质是解耦请求与处理，让请求在处理链中能进行传递与被处理；理解责任链模式应当理解其模式，而不是其具体实现。责任链模式的独到之处是将其节点处理者组合成了链式结构，并允许节点自身决定是否进行请求处理或转发，相当于让请求流动起来。

package chainOfResponsibility;
public class ChainOfResponsibilityPattern {
  public static void main(String[] args) {
    //组装责任链
    Handler handler1 = new ConcreteHandler1();
    Handler handler2 = new ConcreteHandler2();
    handler1.setNext(handler2);
    //提交请求
    handler1.handleRequest("two");
  }
}
//抽象处理者角色
abstract class Handler {
  private Handler next;
  public void setNext(Handler next) {
    this.next = next;
  }
  public Handler getNext() {
    return next;
  }
  //处理请求的方法
  public abstract void handleRequest(String request);
}
//具体处理者角色1
class ConcreteHandler1 extends Handler {
  public void handleRequest(String request) {
    if (request.equals("one")) {
      System.out.println("具体处理者1负责处理该请求！");
    } else {
      if (getNext() != null) {
        getNext().handleRequest(request);
      } else {
        System.out.println("没有人处理该请求！");
      }
    }
  }
}
//具体处理者角色2
class ConcreteHandler2 extends Handler {
  public void handleRequest(String request) {
    if (request.equals("two")) {
      System.out.println("具体处理者2负责处理该请求！");
    } else {
      if (getNext() != null) {
        getNext().handleRequest(request);
      } else {
        System.out.println("没有人处理该请求！");
      }
    }
  }
}

输出：

具体处理者2负责处理该请求！

17.状态模式 ☆

概述

引入：在软件开发过程中，应用程序中的部分对象可能会根据不同的情况做出不同的行为，我们把这种对象称为有状态的对象，而把影响对象行为的一个或多个动态变化的属性称为状态。当有状态的对象与外部事件产生互动时，其内部状态就会发生改变，从而使其行为也发生改变。如人都有高兴和伤心的时候，不同的情绪有不同的行为，当然外界也会影响其情绪变化。

定义：对有状态的对象，把复杂的“判断逻辑”提取到不同的状态对象中，允许状态对象在其内部状态发生改变时改变其行为。

优点：

1. 结构清晰，状态模式将与特定状态相关的行为局部化到一个状态中，并且将不同状态的行为分割开来，满足“单一职责原则”。
2. 将状态转换显示化，减少对象间的相互依赖。将不同的状态引入独立的对象中会使得状态转换变得更加明确，且减少对象间的相互依赖。
3. 状态类职责明确，有利于程序的扩展。通过定义新的子类很容易地增加新的状态和转换。

缺点：

1. 状态模式的使用必然会增加系统的类与对象的个数。
2. 状态模式的结构与实现都较为复杂，如果使用不当会导致程序结构和代码的混乱。
3. 状态模式对开闭原则的支持并不太好，对于可以切换状态的状态模式，增加新的状态类需要修改那些负责状态转换的源码，否则无法切换到新增状态，而且修改某个状态类的行为也需要修改对应类的源码。

应用场景：

• 当一个对象的行为取决于它的状态，并且它必须在运行时根据状态改变它的行为时，就可以考虑使用状态模式。
• 一个操作中含有庞大的分支结构，并且这些分支决定于对象的状态时。

结构与实现

状态模式把受环境改变的对象行为包装在不同的状态对象里，其意图是让一个对象在其内部状态改变的时候，其行为也随之改变。现在我们来分析其基本结构和实现方法。

状态模式包含以下主要角色。

1. 环境类（Context）角色：也称为上下文，它定义了客户端需要的接口，内部维护一个当前状态，并负责具体状态的切换。
2. 抽象状态（State）角色：定义一个接口，用以封装环境对象中的特定状态所对应的行为，可以有一个或多个行为。
3. 具体状态（Concrete State）角色：实现抽象状态所对应的行为，并且在需要的情况下进行状态切换。

public class StatePatternClient {
  public static void main(String[] args) {
    Context context = new Context();    //创建环境      
    context.Handle();    //处理请求
    context.Handle();
    context.Handle();
    context.Handle();
  }
}
//环境类
class Context {
  private State state;
  //定义环境类的初始状态
  public Context() {
    this.state = new ConcreteStateA();
  }
  //设置新状态
  public void setState(State state) {
    this.state = state;
  }
  //读取状态
  public State getState() {
    return (state);
  }
  //对请求做处理
  public void Handle() {
    state.Handle(this);
  }
}
//抽象状态类
abstract class State {
  public abstract void Handle(Context context);
}
//具体状态A类
class ConcreteStateA extends State {
  public void Handle(Context context) {
    System.out.println("当前状态是 A.");
    context.setState(new ConcreteStateB());
  }
}
//具体状态B类
class ConcreteStateB extends State {
  public void Handle(Context context) {
    System.out.println("当前状态是 B.");
    context.setState(new ConcreteStateA());
  }
}

输出

当前状态是 A.
当前状态是 B.
当前状态是 A.
当前状态是 B.

扩展：状态共享

在有些情况下，可能有多个环境对象需要共享一组状态，这时需要引入享元模式，将这些具体状态对象放在集合中供程序共享，其结构图如图 5 所示。

分析：共享状态模式的不同之处是在环境类中增加了一个 HashMap 来保存相关状态，当需要某种状态时可以从中获取，其程序代码如下：

package state;
import java.util.HashMap;
public class FlyweightStatePattern {
  public static void main(String[] args) {
    ShareContext context = new ShareContext(); //创建环境      
    context.Handle(); //处理请求
    context.Handle();
    context.Handle();
    context.Handle();
  }
}
//环境类
class ShareContext {
  private ShareState state;
  private HashMap<String, ShareState> stateSet = new HashMap<String, ShareState>();
  public ShareContext() {
    state = new ConcreteState1();
    stateSet.put("1", state);
    state = new ConcreteState2();
    stateSet.put("2", state);
    state = getState("1");
  }
  //设置新状态
  public void setState(ShareState state) {
    this.state = state;
  }
  //读取状态
  public ShareState getState(String key) {
    ShareState s = (ShareState) stateSet.get(key);
    return s;
  }
  //对请求做处理
  public void Handle() {
    state.Handle(this);
  }
}
//抽象状态类
abstract class ShareState {
  public abstract void Handle(ShareContext context);
}
//具体状态1类
class ConcreteState1 extends ShareState {
  public void Handle(ShareContext context) {
    System.out.println("当前状态是： 状态1");
    context.setState(context.getState("2"));
  }
}
//具体状态2类
class ConcreteState2 extends ShareState {
  public void Handle(ShareContext context) {
    System.out.println("当前状态是： 状态2");
    context.setState(context.getState("1"));
  }
}

输出

当前状态是： 状态1
当前状态是： 状态2
当前状态是： 状态1
当前状态是： 状态2

区别

状态模式与责任链模式的区别

状态模式和责任链模式都能消除 if-else 分支过多的问题。但在某些情况下，状态模式中的状态可以理解为责任，那么在这种情况下，两种模式都可以使用。

从定义来看，状态模式强调的是一个对象内在状态的改变，而责任链模式强调的是外部节点对象间的改变。

从代码实现上来看，两者最大的区别就是状态模式的各个状态对象知道自己要进入的下一个状态对象，而责任链模式并不清楚其下一个节点处理对象，因为链式组装由客户端负责。

状态模式与策略模式的区别

状态模式和策略模式的 UML 类图架构几乎完全一样，但两者的应用场景是不一样的。策略模式的多种算法行为择其一都能满足，彼此之间是独立的，用户可自行更换策略算法，而状态模式的各个状态间存在相互关系，彼此之间在一定条件下存在自动切换状态的效果，并且用户无法指定状态，只能设置初始状态。

18.观察者模式 ☆

概述

引入：在现实世界中，许多对象并不是独立存在的，其中一个对象的行为发生改变可能会导致一个或者多个其他对象的行为也发生改变。例如，某种商品的物价上涨时会导致部分商家高兴，而消费者伤心；还有，当我们开车到交叉路口时，遇到红灯会停，遇到绿灯会行。这样的例子还有很多，例如，股票价格与股民、微信公众号与微信用户、气象局的天气预报与听众、小偷与警察等。

定义：指多个对象间存在一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。这种模式有时又称作发布-订阅模式、模型-视图模式，它是对象行为型模式。

优点：

1. 降低了目标与观察者之间的耦合关系，两者之间是抽象耦合关系。符合依赖倒置原则。
2. 目标与观察者之间建立了一套触发机制。

缺点：

1. 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。
2. 当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。

应用场景：

在软件系统中，当系统一方行为依赖另一方行为的变动时，可使用观察者模式松耦合联动双方，使得一方的变动可以通知到感兴趣的另一方对象，从而让另一方对象对此做出响应。

通过前面的分析与应用实例可知观察者模式适合以下几种情形。

1. 对象间存在一对多关系，一个对象的状态发生改变会影响其他对象。
2. 当一个抽象模型有两个方面，其中一个方面依赖于另一方面时，可将这二者封装在独立的对象中以使它们可以各自独立地改变和复用。
3. 实现类似广播机制的功能，不需要知道具体收听者，只需分发广播，系统中感兴趣的对象会自动接收该广播。
4. 多层级嵌套使用，形成一种链式触发机制，使得事件具备跨域（跨越两种观察者类型）通知。

结构与实现

实现观察者模式时要注意具体目标对象和具体观察者对象之间不能直接调用，否则将使两者之间紧密耦合起来，这违反了面向对象的设计原则。

观察者模式的主要角色如下。

1. 抽象主题（Subject）角色：也叫抽象目标类，它提供了一个用于保存观察者对象的聚集类和增加、删除观察者对象的方法，以及通知所有观察者的抽象方法。
2. 具体主题（Concrete Subject）角色：也叫具体目标类，它实现抽象目标中的通知方法，当具体主题的内部状态发生改变时，通知所有注册过的观察者对象。
3. 抽象观察者（Observer）角色：它是一个抽象类或接口，它包含了一个更新自己的抽象方法，当接到具体主题的更改通知时被调用。
4. 具体观察者（Concrete Observer）角色：实现抽象观察者中定义的抽象方法，以便在得到目标的更改通知时更新自身的状态。

package net.biancheng.c.observer;
import java.util.*;
public class ObserverPattern {
  public static void main(String[] args) {
    Subject subject = new ConcreteSubject();
    Observer obs1 = new ConcreteObserver1();
    Observer obs2 = new ConcreteObserver2();
    subject.add(obs1);
    subject.add(obs2);
    subject.notifyObserver();
  }
}
//抽象目标
abstract class Subject {
  protected List<Observer> observers = new ArrayList<Observer>();
  //增加观察者方法
  public void add(Observer observer) {
    observers.add(observer);
  }
  //删除观察者方法
  public void remove(Observer observer) {
    observers.remove(observer);
  }
  public abstract void notifyObserver(); //通知观察者方法
}
//具体目标
class ConcreteSubject extends Subject {
  public void notifyObserver() {
    System.out.println("具体目标发生改变...");
    System.out.println("--------------");
    for (Object obs : observers) {
      ((Observer) obs).response();
    }
  }
}
//抽象观察者
interface Observer {
  void response(); //反应
}
//具体观察者1
class ConcreteObserver1 implements Observer {
  public void response() {
    System.out.println("具体观察者1作出反应！");
  }
}
//具体观察者1
class ConcreteObserver2 implements Observer {
  public void response() {
    System.out.println("具体观察者2作出反应！");
  }
}

输出

具体目标发生改变...
--------------
具体观察者1作出反应！
具体观察者2作出反应！

19.中介者模式 ☆

概述

引入：

• 在现实生活中，常常会出现好多对象之间存在复杂的交互关系，这种交互关系常常是“网状结构”，它要求每个对象都必须知道它需要交互的对象。例如，每个人必须记住他（她）所有朋友的电话；而且，朋友中如果有人的电话修改了，他（她）必须让其他所有的朋友一起修改，这叫作“牵一发而动全身”，非常复杂。
• 如果把这种“网状结构”改为“星形结构”的话，将大大降低它们之间的“耦合性”，这时只要找一个“中介者”就可以了。如前面所说的“每个人必须记住所有朋友电话”的问题，只要在网上建立一个每个朋友都可以访问的“通信录”就解决了。这样的例子还有很多，例如，你刚刚参加工作想租房，可以找“房屋中介”；或者，自己刚刚到一个陌生城市找工作，可以找“人才交流中心”帮忙。
• 在软件的开发过程中，这样的例子也很多，例如，在 MVC 框架中，控制器（C）就是模型（M）和视图（V）的中介者；还有大家常用的 QQ 聊天程序的“中介者”是 QQ 服务器。所有这些，都可以采用“中介者模式”来实现，它将大大降低对象之间的耦合性，提高系统的灵活性。

定义：定义一个中介对象来封装一系列对象之间的交互，使原有对象之间的耦合松散，且可以独立地改变它们之间的交互。中介者模式又叫调停模式，它是迪米特法则的典型应用。

优点：

1. 类之间各司其职，符合迪米特法则。
2. 降低了对象之间的耦合性，使得对象易于独立地被复用。
3. 将对象间的一对多关联转变为一对一的关联，提高系统的灵活性，使得系统易于维护和扩展。

缺点：中介者模式将原本多个对象直接的相互依赖变成了中介者和多个同事类的依赖关系。当同事类越多时，中介者就会越臃肿，变得复杂且难以维护。

应用场景：

• 当对象之间存在复杂的网状结构关系而导致依赖关系混乱且难以复用时。
• 当想创建一个运行于多个类之间的对象，又不想生成新的子类时。

结构与实现

中介者模式包含以下主要角色。

1. 抽象中介者（Mediator）角色：它是中介者的接口，提供了同事对象注册与转发同事对象信息的抽象方法。
2. 具体中介者（Concrete Mediator）角色：实现中介者接口，定义一个 List 来管理同事对象，协调各个同事角色之间的交互关系，因此它依赖于同事角色。
3. 抽象同事类（Colleague）角色：定义同事类的接口，保存中介者对象，提供同事对象交互的抽象方法，实现所有相互影响的同事类的公共功能。
4. 具体同事类（Concrete Colleague）角色：是抽象同事类的实现者，当需要与其他同事对象交互时，由中介者对象负责后续的交互。

package net.biancheng.c.mediator;
import java.util.*;
public class MediatorPattern {
  public static void main(String[] args) {
    Mediator md = new ConcreteMediator();
    Colleague c1, c2;
    c1 = new ConcreteColleague1();
    c2 = new ConcreteColleague2();
    md.register(c1);
    md.register(c2);
    c1.send();
    System.out.println("-------------");
    c2.send();
  }
}
//抽象中介者
abstract class Mediator {
  public abstract void register(Colleague colleague);
  public abstract void relay(Colleague cl); //转发
}
//具体中介者
class ConcreteMediator extends Mediator {
  private List<Colleague> colleagues = new ArrayList<Colleague>();
  public void register(Colleague colleague) {
    if (!colleagues.contains(colleague)) {
      colleagues.add(colleague);
      colleague.setMedium(this);
    }
  }
  public void relay(Colleague cl) {
    for (Colleague ob : colleagues) {
      if (!ob.equals(cl)) { //除了发送方，其他都通知
        ((Colleague) ob).receive();
      }
    }
  }
}
//抽象同事类
abstract class Colleague {
  protected Mediator mediator;
  public void setMedium(Mediator mediator) {
    this.mediator = mediator;
  }
  public abstract void receive();
  public abstract void send();
}
//具体同事类
class ConcreteColleague1 extends Colleague {
  public void receive() {
    System.out.println("具体同事类1收到请求。");
  }
  public void send() {
    System.out.println("具体同事类1发出请求。");
    mediator.relay(this); //请中介者转发
  }
}
//具体同事类
class ConcreteColleague2 extends Colleague {
  public void receive() {
    System.out.println("具体同事类2收到请求。");
  }
  public void send() {
    System.out.println("具体同事类2发出请求。");
    mediator.relay(this); //请中介者转发
  }
}

输出

具体同事类1发出请求。
具体同事类2收到请求。
-------------
具体同事类2发出请求。
具体同事类1收到请求。

扩展：简化中介者

在实际开发中，通常采用以下两种方法来简化中介者模式，使开发变得更简单。

1. 不定义中介者接口，把具体中介者对象实现成为单例。
2. 同事对象不持有中介者，而是在需要的时候直接获取中介者对象并调用。

package net.biancheng.c.mediator;
import java.util.*;
public class SimpleMediatorPattern {
  public static void main(String[] args) {
    SimpleColleague c1, c2;
    c1 = new SimpleConcreteColleague1();
    c2 = new SimpleConcreteColleague2();
    c1.send();
    System.out.println("-----------------");
    c2.send();
  }
}
//简单单例中介者
class SimpleMediator {
  private static SimpleMediator smd = new SimpleMediator();
  private List<SimpleColleague> colleagues = new ArrayList<SimpleColleague>();
  private SimpleMediator() {
  }
  public static SimpleMediator getMedium() {
    return (smd);
  }
  public void register(SimpleColleague colleague) {
    if (!colleagues.contains(colleague)) {
      colleagues.add(colleague);
    }
  }
  public void relay(SimpleColleague scl) {
    for (SimpleColleague ob : colleagues) {
      if (!ob.equals(scl)) {
        ((SimpleColleague) ob).receive();
      }
    }
  }
}
//抽象同事类
interface SimpleColleague {
  void receive();
  void send();
}
//具体同事类
class SimpleConcreteColleague1 implements SimpleColleague {
  SimpleConcreteColleague1() {
    SimpleMediator smd = SimpleMediator.getMedium();
    smd.register(this);
  }
  public void receive() {
    System.out.println("具体同事类1：收到请求。");
  }
  public void send() {
    SimpleMediator smd = SimpleMediator.getMedium();
    System.out.println("具体同事类1：发出请求...");
    smd.relay(this); //请中介者转发
  }
}
//具体同事类
class SimpleConcreteColleague2 implements SimpleColleague {
  SimpleConcreteColleague2() {
    SimpleMediator smd = SimpleMediator.getMedium();
    smd.register(this);
  }
  public void receive() {
    System.out.println("具体同事类2：收到请求。");
  }
  public void send() {
    SimpleMediator smd = SimpleMediator.getMedium();
    System.out.println("具体同事类2：发出请求...");
    smd.relay(this); //请中介者转发
  }
}

输出

具体同事类1：发出请求...
具体同事类2：收到请求。
-----------------
具体同事类2：发出请求...
具体同事类1：收到请求。

20.迭代器模式

概述

引入：

• 迭代器在客户访问类与聚合类之间插入一个迭代器，这分离了聚合对象与其遍历行为，对客户也隐藏了其内部细节，且满足“单一职责原则”和“开闭原则”，如 Java 中的 Collection、List、Set、Map 等都包含了迭代器。
• 迭代器模式在生活中应用的比较广泛，比如：物流系统中的传送带，不管传送的是什么物品，都会被打包成一个个箱子，并且有一个统一的二维码。这样我们不需要关心箱子里是什么，在分发时只需要一个个检查发送的目的地即可。再比如，我们平时乘坐交通工具，都是统一刷卡或者刷脸进站，而不需要关心是男性还是女性、是残疾人还是正常人等信息。

定义：提供一个对象来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

优点：

1. 访问一个聚合对象的内容而无须暴露它的内部表示。
2. 遍历任务交由迭代器完成，这简化了聚合类。
3. 它支持以不同方式遍历一个聚合，甚至可以自定义迭代器的子类以支持新的遍历。
4. 增加新的聚合类和迭代器类都很方便，无须修改原有代码。
5. 封装性良好，为遍历不同的聚合结构提供一个统一的接口。

缺点：增加了类的个数，这在一定程度上增加了系统的复杂性。

在日常开发中，我们几乎不会自己写迭代器。除非需要定制一个自己实现的数据结构对应的迭代器，否则，开源框架提供的 API 完全够用。

结构与实现

迭代器模式是通过将聚合对象的遍历行为分离出来，抽象成迭代器类来实现的，其目的是在不暴露聚合对象的内部结构的情况下，让外部代码透明地访问聚合的内部数据。现在我们来分析其基本结构与实现方法。

迭代器模式主要包含以下角色。

1. 抽象聚合（Aggregate）角色：定义存储、添加、删除聚合对象以及创建迭代器对象的接口。
2. 具体聚合（ConcreteAggregate）角色：实现抽象聚合类，返回一个具体迭代器的实例。
3. 抽象迭代器（Iterator）角色：定义访问和遍历聚合元素的接口，通常包含 hasNext()、first()、next() 等方法。
4. 具体迭代器（Concretelterator）角色：实现抽象迭代器接口中所定义的方法，完成对聚合对象的遍历，记录遍历的当前位置。

package net.biancheng.c.iterator;
import java.util.*;
public class IteratorPattern {
  public static void main(String[] args) {
    Aggregate ag = new ConcreteAggregate();
    ag.add("中山大学");
    ag.add("华南理工");
    ag.add("韶关学院");
    System.out.print("聚合的内容有：");
    Iterator it = ag.getIterator();
    while (it.hasNext()) {
      Object ob = it.next();
      System.out.print(ob.toString() + "\t");
    }
    Object ob = it.first();
    System.out.println("\nFirst：" + ob.toString());
  }
}
//抽象聚合
interface Aggregate {
  public void add(Object obj);
  public void remove(Object obj);
  public Iterator getIterator();
}
//具体聚合
class ConcreteAggregate implements Aggregate {
  private List<Object> list = new ArrayList<Object>();
  public void add(Object obj) {
    list.add(obj);
  }
  public void remove(Object obj) {
    list.remove(obj);
  }
  public Iterator getIterator() {
    return (new ConcreteIterator(list));
  }
}
//抽象迭代器
interface Iterator {
  Object first();
  Object next();
  boolean hasNext();
}
//具体迭代器
class ConcreteIterator implements Iterator {
  private List<Object> list = null;
  private int index = -1;
  public ConcreteIterator(List<Object> list) {
    this.list = list;
  }
  public boolean hasNext() {
    if (index < list.size() - 1) {
      return true;
    } else {
      return false;
    }
  }
  public Object first() {
    index = 0;
    Object obj = list.get(index);
    return obj;
  }
  public Object next() {
    Object obj = null;
    if (this.hasNext()) {
      obj = list.get(++index);
    }
    return obj;
  }
}

输出

聚合的内容有：中山大学    华南理工    韶关学院   
First：中山大学

21.访问者模式

概述

引入：

• 在现实生活中，有些集合对象存在多种不同的元素，且每种元素也存在多种不同的访问者和处理方式。例如，公园中存在多个景点，也存在多个游客，不同的游客对同一个景点的评价可能不同；医院医生开的处方单中包含多种药元素，査看它的划价员和药房工作人员对它的处理方式也不同，划价员根据处方单上面的药品名和数量进行划价，药房工作人员根据处方单的内容进行抓药。
• 这样的例子还有很多，例如，电影或电视剧中的人物角色，不同的观众对他们的评价也不同；还有顾客在商场购物时放在“购物车”中的商品，顾客主要关心所选商品的性价比，而收银员关心的是商品的价格和数量。
• 这些被处理的数据元素相对稳定而访问方式多种多样的数据结构，如果用“访问者模式”来处理比较方便。访问者模式能把处理方法从数据结构中分离出来，并可以根据需要增加新的处理方法，且不用修改原来的程序代码与数据结构，这提高了程序的扩展性和灵活性。

定义：将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作，为数据结构中的每个元素提供多种访问方式。它将对数据的操作与数据结构进行分离，是行为类模式中最复杂的一种模式。

优点：

1. 扩展性好。能够在不修改对象结构中的元素的情况下，为对象结构中的元素添加新的功能。
2. 复用性好。可以通过访问者来定义整个对象结构通用的功能，从而提高系统的复用程度。
3. 灵活性好。访问者模式将数据结构与作用于结构上的操作解耦，使得操作集合可相对自由地演化而不影响系统的数据结构。
4. 符合单一职责原则。访问者模式把相关的行为封装在一起，构成一个访问者，使每一个访问者的功能都比较单一。

缺点：

1. 增加新的元素类很困难。在访问者模式中，每增加一个新的元素类，都要在每一个具体访问者类中增加相应的具体操作，这违背了“开闭原则”。
2. 破坏封装。访问者模式中具体元素对访问者公布细节，这破坏了对象的封装性。
3. 违反了依赖倒置原则。访问者模式依赖了具体类，而没有依赖抽象类。

应用场景：

当系统中存在类型数量稳定（固定）的一类数据结构时，可以使用访问者模式方便地实现对该类型所有数据结构的不同操作，而又不会对数据产生任何副作用（脏数据）。简而言之，就是当对集合中的不同类型数据（类型数量稳定）进行多种操作时，使用访问者模式。

通常在以下情况可以考虑使用访问者（Visitor）模式。

1. 对象结构相对稳定，但其操作算法经常变化的程序。
2. 对象结构中的对象需要提供多种不同且不相关的操作，而且要避免让这些操作的变化影响对象的结构。
3. 对象结构包含很多类型的对象，希望对这些对象实施一些依赖于其具体类型的操作。

结构与实现

访问者（Visitor）模式实现的关键是如何将作用于元素的操作分离出来封装成独立的类，其基本结构与实现方法如下。

访问者模式包含以下主要角色。

1. 抽象访问者（Visitor）角色：定义一个访问具体元素的接口，为每个具体元素类对应一个访问操作 visit() ，该操作中的参数类型标识了被访问的具体元素。
2. 具体访问者（ConcreteVisitor）角色：实现抽象访问者角色中声明的各个访问操作，确定访问者访问一个元素时该做什么。
3. 抽象元素（Element）角色：声明一个包含接受操作 accept() 的接口，被接受的访问者对象作为 accept() 方法的参数。
4. 具体元素（ConcreteElement）角色：实现抽象元素角色提供的 accept() 操作，其方法体通常都是 visitor.visit(this) ，另外具体元素中可能还包含本身业务逻辑的相关操作。
5. 对象结构（Object Structure）角色：是一个包含元素角色的容器，提供让访问者对象遍历容器中的所有元素的方法，通常由 List、Set、Map 等聚合类实现。

package net.biancheng.c.visitor;
import java.util.*;
public class VisitorPattern {
  public static void main(String[] args) {
    ObjectStructure os = new ObjectStructure();
    os.add(new ConcreteElementA());
    os.add(new ConcreteElementB());
    Visitor visitor = new ConcreteVisitorA();
    os.accept(visitor);
    System.out.println("------------------------");
    visitor = new ConcreteVisitorB();
    os.accept(visitor);
  }
}
//抽象访问者
interface Visitor {
  void visit(ConcreteElementA element);
  void visit(ConcreteElementB element);
}
//具体访问者A类
class ConcreteVisitorA implements Visitor {
  public void visit(ConcreteElementA element) {
    System.out.println("具体访问者A访问-->" + element.operationA());
  }
  public void visit(ConcreteElementB element) {
    System.out.println("具体访问者A访问-->" + element.operationB());
  }
}
//具体访问者B类
class ConcreteVisitorB implements Visitor {
  public void visit(ConcreteElementA element) {
    System.out.println("具体访问者B访问-->" + element.operationA());
  }
  public void visit(ConcreteElementB element) {
    System.out.println("具体访问者B访问-->" + element.operationB());
  }
}
//抽象元素类
interface Element {
  void accept(Visitor visitor);
}
//具体元素A类
class ConcreteElementA implements Element {
  public void accept(Visitor visitor) {
    visitor.visit(this);
  }
  public String operationA() {
    return "具体元素A的操作。";
  }
}
//具体元素B类
class ConcreteElementB implements Element {
  public void accept(Visitor visitor) {
    visitor.visit(this);
  }
  public String operationB() {
    return "具体元素B的操作。";
  }
}
//对象结构角色
class ObjectStructure {
  private List<Element> list = new ArrayList<Element>();
  public void accept(Visitor visitor) {
    Iterator<Element> i = list.iterator();
    while (i.hasNext()) {
      ((Element) i.next()).accept(visitor);
    }
  }
  public void add(Element element) {
    list.add(element);
  }
  public void remove(Element element) {
    list.remove(element);
  }
}

输出

具体访问者A访问-->具体元素A的操作。
具体访问者A访问-->具体元素B的操作。
------------------------
具体访问者B访问-->具体元素A的操作。
具体访问者B访问-->具体元素B的操作。

22.备忘录模式

概述

引入：

• 每个人都有犯错误的时候，都希望有种“后悔药”能弥补自己的过失，让自己重新开始，但现实是残酷的。在计算机应用中，客户同样会常常犯错误，能否提供“后悔药”给他们呢？当然是可以的，而且是有必要的。这个功能由“备忘录模式”来实现。
• 其实很多应用软件都提供了这项功能，如 Word、记事本、Photoshop、Eclipse 等软件在编辑时按 Ctrl+Z 组合键时能撤销当前操作，使文档恢复到之前的状态；还有在 IE 中的后退键、数据库事务管理中的回滚操作、玩游戏时的中间结果存档功能、数据库与操作系统的备份操作、棋类游戏中的悔棋功能等都属于这类。
• 备忘录模式能记录一个对象的内部状态，当用户后悔时能撤销当前操作，使数据恢复到它原先的状态。

定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，以便以后当需要时能将该对象恢复到原先保存的状态。该模式又叫快照模式。

优点：

• 提供了一种可以恢复状态的机制。当用户需要时能够比较方便地将数据恢复到某个历史的状态。
• 实现了内部状态的封装。除了创建它的发起人之外，其他对象都不能够访问这些状态信息。
• 简化了发起人类。发起人不需要管理和保存其内部状态的各个备份，所有状态信息都保存在备忘录中，并由管理者进行管理，这符合单一职责原则。

缺点：资源消耗大。如果要保存的内部状态信息过多或者特别频繁，将会占用比较大的内存资源。

应用场景：

1. 需要保存与恢复数据的场景，如玩游戏时的中间结果的存档功能。

2. 需要提供一个可回滚操作的场景，如 Word、记事本、Photoshop，Eclipse 等软件在编辑时按 Ctrl+Z 组合键，还有数据库中事务操作。

结构与实现

备忘录模式的主要角色如下。

1. 发起人（Originator）角色：记录当前时刻的内部状态信息，提供创建备忘录和恢复备忘录数据的功能，实现其他业务功能，它可以访问备忘录里的所有信息。
2. 备忘录（Memento）角色：负责存储发起人的内部状态，在需要的时候提供这些内部状态给发起人。
3. 管理者（Caretaker）角色：对备忘录进行管理，提供保存与获取备忘录的功能，但其不能对备忘录的内容进行访问与修改。

package net.biancheng.c.memento;
public class MementoPattern {
  public static void main(String[] args) {
    Originator or = new Originator();
    Caretaker cr = new Caretaker();
    or.setState("S0");
    System.out.println("初始状态:" + or.getState());
    cr.setMemento(or.createMemento()); //保存状态
    or.setState("S1");
    System.out.println("新的状态:" + or.getState());
    or.restoreMemento(cr.getMemento()); //恢复状态
    System.out.println("恢复状态:" + or.getState());
  }
}
//备忘录
class Memento {
  private String state;
  public Memento(String state) {
    this.state = state;
  }
  public void setState(String state) {
    this.state = state;
  }
  public String getState() {
    return state;
  }
}
//发起人
class Originator {
  private String state;
  public void setState(String state) {
    this.state = state;
  }
  public String getState() {
    return state;
  }
  public Memento createMemento() {
    return new Memento(state);
  }
  public void restoreMemento(Memento m) {
    this.setState(m.getState());
  }
}
//管理者
class Caretaker {
  private Memento memento;
  public void setMemento(Memento m) {
    memento = m;
  }
  public Memento getMemento() {
    return memento;
  }
}

输出

初始状态:S0
新的状态:S1
恢复状态:S0

扩展：原型模式搭配

在前面介绍的备忘录模式中，有单状态备份的例子，也有多状态备份的例子。下面介绍备忘录模式如何同原型模式混合使用。在备忘录模式中，通过定义“备忘录”来备份“发起人”的信息，而原型模式的 clone() 方法具有自备份功能，所以，如果让发起人实现 Cloneable 接口就有备份自己的功能，这时可以删除备忘录类，其结构图如图 4 所示。

package net.biancheng.c.memento;
public class PrototypeMemento {
  public static void main(String[] args) {
    OriginatorPrototype or = new OriginatorPrototype();
    PrototypeCaretaker cr = new PrototypeCaretaker();
    or.setState("S0");
    System.out.println("初始状态:" + or.getState());
    cr.setMemento(or.createMemento()); //保存状态
    or.setState("S1");
    System.out.println("新的状态:" + or.getState());
    or.restoreMemento(cr.getMemento()); //恢复状态
    System.out.println("恢复状态:" + or.getState());
  }
}
//发起人原型
class OriginatorPrototype implements Cloneable {
  private String state;
  public void setState(String state) {
    this.state = state;
  }
  public String getState() {
    return state;
  }
  public OriginatorPrototype createMemento() {
    return this.clone();
  }
  public void restoreMemento(OriginatorPrototype opt) {
    this.setState(opt.getState());
  }
  public OriginatorPrototype clone() {
    try {
      return (OriginatorPrototype) super.clone();
    } catch (CloneNotSupportedException e) {
      e.printStackTrace();
    }
    return null;
  }
}
//原型管理者
class PrototypeCaretaker {
  private OriginatorPrototype opt;
  public void setMemento(OriginatorPrototype opt) {
    this.opt = opt;
  }
  public OriginatorPrototype getMemento() {
    return opt;
  }
}

23.解释器模式

概述

引入：

• 在软件开发中，会遇到有些问题多次重复出现，而且有一定的相似性和规律性。如果将它们归纳成一种简单的语言，那么这些问题实例将是该语言的一些句子，这样就可以用“编译原理”中的解释器模式来实现了。

• 虽然使用解释器模式的实例不是很多，但对于满足以上特点，且对运行效率要求不是很高的应用实例，如果用解释器模式来实现，其效果是非常好的，本文将介绍其工作原理与使用方法。

定义：给分析对象定义一个语言，并定义该语言的文法表示，再设计一个解析器来解释语言中的句子。也就是说，用编译语言的方式来分析应用中的实例。这种模式实现了文法表达式处理的接口，该接口解释一个特定的上下文。

• 这里提到的文法和句子的概念同编译原理中的描述相同，“文法”指语言的语法规则，而“句子”是语言集中的元素。例如，汉语中的句子有很多，“我是中国人”是其中的一个句子，可以用一棵语法树来直观地描述语言中的句子。

优点：

1. 扩展性好。由于在解释器模式中使用类来表示语言的文法规则，因此可以通过继承等机制来改变或扩展文法。
2. 容易实现。在语法树中的每个表达式节点类都是相似的，所以实现其文法较为容易。

缺点：

1. 执行效率较低。解释器模式中通常使用大量的循环和递归调用，当要解释的句子较复杂时，其运行速度很慢，且代码的调试过程也比较麻烦。
2. 会引起类膨胀。解释器模式中的每条规则至少需要定义一个类，当包含的文法规则很多时，类的个数将急剧增加，导致系统难以管理与维护。
3. 可应用的场景比较少。在软件开发中，需要定义语言文法的应用实例非常少，所以这种模式很少被使用到。

详见：http://c.biancheng.net/view/1402.html

应用场景：

1. 当语言的文法较为简单，且执行效率不是关键问题时。
2. 当问题重复出现，且可以用一种简单的语言来进行表达时。
3. 当一个语言需要解释执行，并且语言中的句子可以表示为一个抽象语法树的时候，如 XML 文档解释。

总结：一句话归纳设计模式

回到顶部

分类	设计模式	简述	一句话归纳	目的	生活案例
创建型设计模式 （简单来说就是用来创建对象的）	工厂模式（Factory Pattern）	不同条件下创建不同实例	产品标准化，生产更高效	封装创建细节	实体工厂
单例模式（Singleton Pattern）	保证一个类仅有一个实例，并且提供一个全局访问点	世上只有一个我	保证独一无二	CEO
原型模式（Prototype Pattern）	通过拷贝原型创建新的对象	拔一根猴毛，吹出千万个	高效创建对象	克隆
建造者模式（Builder Pattern）	用来创建复杂的复合对象	高配中配和低配，想选哪配就哪配	开放个性配置步骤	选配
结构型设计模式 （关注类和对象的组合）	代理模式（Proxy Pattern）	为其他对象提供一种代理以控制对这个对象的访问	没有资源没时间，得找别人来帮忙	增强职责	媒婆
外观模式（Facade Pattern）	对外提供一个统一的接口用来访问子系统	打开一扇门，通向全世界	统一访问入口	前台
装饰器模式（Decorator Pattern）	为对象添加新功能	他大舅他二舅都是他舅	灵活扩展、同宗同源	煎饼
享元模式（Flyweight Pattern）	使用对象池来减少重复对象的创建	优化资源配置，减少重复浪费	共享资源池	全国社保联网
组合模式（Composite Pattern）	将整体与局部（树形结构）进行递归组合，让客户端能够以一种的方式对其进行处理	人在一起叫团伙，心在一起叫团队	统一整体和个体	组织架构树
适配器模式（Adapter Pattern）	将原来不兼容的两个类融合在一起	万能充电器	兼容转换	电源适配
桥接模式（Bridge Pattern）	将两个能够独立变化的部分分离开来	约定优于配置	不允许用继承	桥
行为型设计模式 （关注对象之间的通信）	模板模式（Template Pattern）	定义一套流程模板，根据需要实现模板中的操作	流程全部标准化，需要微调请覆盖	逻辑复用	把大象装进冰箱
策略模式（Strategy Pattern）	封装不同的算法，算法之间能互相替换	条条大道通罗马，具体哪条你来定	把选择权交给用户	选择支付方式
责任链模式（Chain of Responsibility Pattern）	拦截的类都实现统一接口，每个接收者都包含对下一个接收者的引用。将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。	各人自扫门前雪，莫管他们瓦上霜	解耦处理逻辑	踢皮球
迭代器模式（Iterator Pattern）	提供一种方法顺序访问一个聚合对象中的各个元素	流水线上坐一天，每个包裹扫一遍	统一对集合的访问方式	逐个检票进站
命令模式（Command Pattern）	将请求封装成命令，并记录下来，能够撤销与重做	运筹帷幄之中，决胜千里之外	解耦请求和处理	遥控器
状态模式（State Pattern）	根据不同的状态做出不同的行为	状态驱动行为，行为决定状态	绑定状态和行为	订单状态跟踪
备忘录模式（Memento Pattern）	保存对象的状态，在需要时进行恢复	失足不成千古恨，想重来时就重来	备份、后悔机制	草稿箱
中介者模式（Mediator Pattern）	将对象之间的通信关联关系封装到一个中介类中单独处理，从而使其耦合松散	联系方式我给你，怎么搞定我不管	统一管理网状资源	朋友圈
解释器模式（Interpreter Pattern）	给定一个语言，定义它的语法表示，并定义一个解释器，这个解释器使用该标识来解释语言中的句子	我想说”方言“，一切解释权都归我	实现特定语法解析	摩斯密码
观察者模式（Observer Pattern）	状态发生改变时通知观察者，一对多的关系	到点就通知我	解耦观察者与被观察者	闹钟
访问者模式（Visitor Pattern）	稳定数据结构，定义新的操作行为	横看成岭侧成峰，远近高低各不同	解耦数据结构和数据操作	KPI考核
	委派模式（Delegate Pattern）	允许对象组合实现与继承相同的代码重用，负责任务的调用和分配	这个需求很简单，怎么实现我不管	只对结果负责	授权委托书