设计模式

定义

什么是设计模式(Design Pattern)

• 代码设计经验的总结
• 被反复使用
• 多数人知晓
• 经过分类编目
• 23种设计模式(创建型、结构型、行为型)

什么时候用设计模式？

代码设计的时候

为什么要使用设计模式？

为了解耦

七大设计原则

单一职责

​ 对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1 职责2。 当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为 A1 A2

注意事项

• 降低类的复杂度，一个类只负责一项职责。
• 提高类的可读性，可维护性 降低变更引起的风险
• 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违 反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

接口隔离

定义：客户端不应该依赖它不需要的接 口，即一个类对另一个类的依赖 应该建立在最小的接口上

示例：

类A通过接口Interface1 依赖类B

类C通过接口 Interface1依赖类D

如果接口 Interface1对于类A和类C来说不是最小接口

那么类B和类D必须去实现他们不需要的方法。

按隔离原则应当这样处理： 将接口 Interface1 拆分为独立的几个接口, 类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则

依赖倒置

• 高层模块不应该依赖低层模块，二者都应该依赖其抽象
• 抽象不应该依赖细节，细节应该依赖抽象
• 依赖倒转（倒置）的中心思想是面向接口编程
• 依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的 多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象 指的是接口或抽象类，细节就是具体的实现类
• 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

依赖关系传递的三种方式

什么叫依赖关系的传递？就是说类A依赖类B，但类A内部不直接new 类B，通过依赖关系传递，让类A能依赖到类B

• 接口方式
• 构造方法 .NET core 的依赖注入就是用的这种方法
• setter方式 感觉spring的依赖注入用的是这种方式

原则和注意事项

1） 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好

2） 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间，就存在 一个缓冲层，利于程序扩展和优化

3） 继承时遵循里氏替换原则

里氏替换

oo中的继承性的思考和说明

1） 继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。

2） 继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承, 则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障

3） 问题提出：在编程中，如何正确的使用继承？=＞里氏替换原则

基本介绍

1） 里氏替换原则（Liskov Substitution Principle）在1988年，由麻省理工学院的一位姓里的女士提出的

2） 如果对每个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序 P中所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T2是类型T1的子类型。换句话说，所有引用基类的地方必须能透明地使用其子类的对象。

3） 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法

4） 里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。

开闭原则

基本介绍

1. 开闭原则(Open Closed Principle)是编程中最基础、最重要的设计原则

2. 一个软件实体如类，模块和函数应该对扩展开放，对修改关闭。用抽象构建框架， 用实现扩展细节。

3)当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。

4)编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。

迪米特法则（最少知道原则）

基本介绍

1） 一个对象应该对其他对象保持最少的了解

2）类与类关系越密切，耦合度越大

3）迪米特法则（Demeter Principle）又叫最少知道原则，即一个类对自己依赖的类知道的 越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内 部。对外除了提供的public方法，不对外泄露任何信息

4）迪米特法则还有个更简单的定义：只与直接的朋友通信

5）直接的朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系, 我们就说这两个对象之间是朋友关系。耦合的方式很多，依赖，关联，组合，聚合 等。其中，我们称出现成员变量，方法参数，方法返回值中的类为直接的朋友，而出现在局部变量中的类不是直接的朋友。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

合成复用

尽量使用合成/聚合的方式，而不是使用继承，因为继承的耦合性更高

UML

基本介绍

1） UML-----Unified modeling language UML （统一建模语言），是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果

2） UML本身是一套符号的规定，就像数学符号和化学符号一样，这些符号用于描述软件模型中的各个元素和他们之间的关系，比如类、接口、实现、泛化、依 赖、组合、聚合等

3） 使用UML来建模，常用的工具有Rational Rose ,也可以使用一些插件来建模

常用关系：

1. 依赖（就是使用，A使用到B，A类有个方法，该方法的返回值或者参数类型是B类）
2. 关联（1对1，多对多）
3. 泛化（继承）
4. 实现（接口实现）
5. 聚合（实际上是关联关系的特例，A类有个成员变量是B类，通过setter方法传递对象实例进来，就叫A类聚合B类）
6. 组合（实际上是关联关系的特例，A类有个成员变量是B类，属性上直接new B类，就叫A类组合B类，组合耦合性比聚合高）

UML图分类

1） 用例图（ use case）

2） 静态结构图：类图、对象图、包图、组件图、部署图

3） 动态行为图：交互图（时序图与协作图）、状态图、活动图

说明：

1） 类图是描述类与类之间的关系的，是UML图中最核心的

类图 - 依赖关系（dependency）

只要是在类中用到了对方，那么他们之间就存在依赖关系。如果没有对方，连编绎都通过不了。

public class PersonServiceBean { 
	private PersonDao personDao;//类 
	public void save(Person person){} 
	public IDCard getIDCard(Integer personid){
        return null;
    }
	public void modify(){
    	Department department = new Department();  
    } 
}
    public class PersonDao{} 
    public class IDCard{} 
    public class Person{} 
    public class Department{}

小结：

1）类中用到了对方

2）如果是类的成员属性

3）如果是方法的返回类型

4）如果是方法接收的参数类型

5）如果是方法的成员变量

类图 - 泛化关系（generalization）

泛化关系实际上就是继承关系，他是依赖关系的特例

public abstract class DaoSupport{

	public void save(Object entity){
	} 
	public void delete(Object id){
	
	}
}
public class PersonServiceBean extends Daosupport{}

类图 - 实现关系（Implementation）

实现关系实际上就是A类实现B类，他是依赖关系的特例

public interface PersonService {
	public void delete(Interger id); 
}

public class PersonServiceBean implements PersonService { 
	public void delete(Interger id){}
}

类图 - 关联关系（Association）

• 关联关系实际上就是类与类之间的联系，他是依赖关系的特例
• 关联具有导航性：即双向关系或单向关系
• 关系具有多重性：如“1” （表示有且仅有一个） ， “0..” （表示0个或者多个） ，“0， 1” （表示0个或者一个） ， “n...m”（表示n到m个都可以），“m..”（表示至少m个）。

关联关系一般是成员属性的一种依赖

单向一对一关系：

public class Person {
	private IDCard card;
}

public class IDCard{}

双向一对一关系:

public class Person { 
	private IDCard card;
}
public class IDCard{ 
	private Person person
}

类图 - 聚合关系（Aggregation）

聚合关系(Aggregation)表示的是整体和部分的关系，整体与部分可以分开。聚合关系是关联关系的特例，所以他具有关联的导航性与多重性。 如：一台电脑由键盘(keyboard)、显示器(monitor)、鼠标等组成；组成电脑的各个配件是可以从电脑上分离出来的：

public class Computer{
	Mouse mouse;
	Monitor monitor：
	public void set Mouse(Mouse mouse){
		this.mouse = mouse;
	}
	public void set Mo nit or(Monitor monitor){
		this.monitor = monitor;
	}
}

如果鼠标、显示器和电脑是不可以分离的，则升级为组合关系

类图 - 组合关系（Composition）

组合关系：也是整体与部分的关系，但是整体与部分不可以分开。 再看一个案例：在程序中我们定义实体：Person与IDCard、Head,那么Head和Person就是组合，IDCard和Person就是聚合。

public class Person{
	private IDCard card;
	private Head head = new Head();
)
public class IDCard{}
public class Head{}

但是如果在程序中Person实体中定义了对IDCard进行级联删除，即删除Person时，连同IDCard一起删除，那么IDCard和Person就是组合关系了

类加载过程

Demo demo = new Demo();

1.分配内存空间（堆中）

2.初始化该内存空间

3.把该空间的地址赋值给demo变量（可能在栈里，也可能在堆中，因为对象可能是Integer或者String这样的常量池），让demo变量指向该空间

类加载过程：

1、加载二进制数据到内存中，生成对应的Class数据结构

2、连接：a.验证，b.准备（给类的静态成员变量赋默认值）,c.解析

3、初始化：给类的静态变量赋初值

设计模式分类

总共23种

创建型

站在对象创建角度

• 单例模式 ***
• 抽象工厂模式
• 原型模式
• 建造者模式
• 工厂模式 ***

结构型

站在整个系统设计角度

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

行为型

站在方法角度

• 模版方法模式
• 命令模式
• 访问者模式
• 迭代器模式
• 观察者模式 ***
• 中介者模式
• 备忘录模式
• 解释器模式（Interpreter模式）
• 状态模式
• 策略模式
• 职责链模式（责任链模式）

创建型模式

• 不直接使用new创建对象

• 屏蔽掉创建对象的过程

• 调用者直接调用方法即可获得对象

• 使得创建对象更加灵活

单例

• 单例类只能有一个对象
• 私有构造，不允许其他类去创建该类的对象
• 单例类必须自己创建自己的唯一实例
• 分类：饿汉式、懒汉式（线程不安全，需要加同步锁）

单例模式注意事项和细节说明:

1） 单例模式保证了系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高系统性能

2） 当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用new(）

单例模式使用的场景：需要频繁的进行创建和销毁的对象、创建对象时耗时过多或耗费资源过多（即：重量级对象），但又经常用到的对象、工具类对象、频繁访问数据库或文件的对象（比如数据源、session工厂等）

实现单例模式有8种方法：

1） 饿汉式（静态常量）

2） 饿汉式（静态代码块）

3） 懒汉式（线程不安全）

4） 懒汉式（线程安全，同步方法）

5） 懒汉式（线程安全，同步代码块）

6） 双重检查

7） 静态内部类

8） 枚举

饿汉式（静态常量）

步骤如下：

1）构造器私有化（防止new ）

2）类的内部创建对象

3）向外暴露一个静态的公共方法。

//饿汉式（静态变量）
class Singleton {
    //1.构造器私有化，外部不能new
    private Singleton() {
    }

    //2.本类内部创建对象实例
    private final static Singleton instance = new Singleton();

    //3.提供一个公有的静态方法，返回实例对象
    public static Singleton getInstance() {
        return instance;
    }
}

优缺点：

1） 优点：这种写法比较简单，就是在类装载的时候就完成实例化。避免了线程同步问题。

2） 缺点：在类装载的时候就完成实例化，没有达到Lazy Loading的效果。如果从始至终从未使用过这个实例，则会造成内存的浪费

3） 这种方式基于classloder机制避免了多线程的同步问题，不过，instance在类装载时就实例化，在单例模式中大多数都是调用getInstance方法，但是导致类装载的原因有很多种，因此不能确定有其他的方式（或者其他的静态方法）导致类装载，这时候初始化instance就没有达到lazy loading的效果

4） 结论：这种单例模式可用，但可能造成内存浪费

只有在真正主动使用对应的类时，才会触发初始化如（当前类是启动类即main函数所在类，直接进行new操作，访问静态属性、访问静态方法，用反射访问类，初始化一个类的子类等）

类加载的初始化阶段就完成了实例的初始化。本质上就是借助于jvm类加载机制，保证实例的唯一性（初始化过程只会执行一次）及线程安全（JVM以同步的形式来完成类加载的整个过程）

通过反射的方式可以让饿汉式的单例模型产生多例：

饿汉式（静态代码块）

//饿汉式（静态变量）
class Singleton {
    //1.构造器私有化，外部不能new
    private Singleton() {
    }

    //2.本类内部创建对象实例
    private static Singleton instance;

    static{
        instance  = new Singleton();
    }

    //3.提供一个公有的静态方法，返回实例对象
    public static Singleton getInstance() {
        return instance;
    }
}

优缺点：

1） 这种方式和上面的方式其实类似，只不过将类实例化的过程放在了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面是一样的。

2） 结论：这种单例模式可用，但是可能造成内存浪费

懒汉式（线程不安全，做不到单例）

class Singleton {
    private static Singleton instance;
    private Singleton() {}
    //提供一个静态的公有方法，当使用到该方法时，才去创建instance
    //即懒汉式
    public static Singleton getInstance() {
        if(instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

优缺点说明：

1） 起到了Lazy Loading的效果，但是只能在单线程下使用。

2） 如果在多线程下，一个线程进入了if （ singleton == null） 判断语句块，还未来得及 往下执行，另一个线程也通过了这个判断语句，这时便会产生多个实例。所以 在多线程环境下不可使用这种方式

3） 结论：在实际开发中，不要使用这种方式

懒汉式 - 同步方法（线程安全）

class Singleton {
    private static Singleton instance;
    private Singleton() {}
    //提供一个静态的公有方法，当使用到该方法时，才去创建instance
    //即懒汉式
    public static synchronized Singleton getInstance() {
        if(instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

优缺点说明：

1） 解决了线程不安全问题

2） 效率太低了，每个线程在想获得类的实例时候，执行getlnstance方法都要进行同步。而其实这个方法只执行一次实例化代码就够了，后面的想获得该类实例, 直接return就行了。方法进行同步效率太低

3） 结论：在实际开发中，不推荐使用这种方式

懒汉式 - 同步代码块（线程不安全，做不到单例）

class Singleton {
    private static Singleton instance;
    private Singleton() {}
    //提供一个静态的公有方法，当使用到该方法时，才去创建instance
    //即懒汉式
    public static Singleton getInstance() {
        if(instance == null) {
            synchronized(Singleton.class) {
                instance = new Singleton();
            }
        }
        return instance;
    }
}

优缺点说明:

1） 这种方式，本意是想对第四种实现方式的改进，因为前面同步方法效率太低， 改为同步产生实例化的的代码块

2） 但是这种同步并不能起到线程同步的作用。跟第3种实现方式遇到的情形一 致，假如一个线程进入了if （ singleton == null） 判断语句块，还未来得及往下执行, 另一个线程也通过了这个判断语句，这时便会产生多个实例

3） 结论：在实际开发中，不能使用这种方式

双重检查 （推荐）

class Singleton {
    //被volatile修饰的变量能够保证每个线程能够获取该变量的最新值，从而避免出现数据脏读的现象。volatile的作用是让下面1、2、3步骤按顺序执行
    //为什么会出现脏读呢？
    //因为instance = new Singleton();  这句话可以被拆分成3句话
    //1.分配内存
    //2.初始化对象
    //3.变量instance指向刚分配的内存地址
    //因为CPU进行了优化，2、3不一定顺序执行，当先执行了3后，某个线程认为已经存在了该对象，但实际上该对象还未初始化，使用该对象就会出错
    private static volatile Singleton instance;
    private Singleton() {}
    //提供一个静态的公有方法，当使用到该方法时，才去创建instance
    //即懒汉式
    public static Singleton getInstance() {
        if(instance == null) {
            synchronized(Singleton.class) {
                if(instance == null)
                    instance = new Singleton();
            }
        }
        return instance;
    }
}

优缺点说明:

1. Double-Check概念是多线程开发中常使用到的，如代码中所示，我们进行了两次if (singleton == null)检查，这样就可以保证线程安全了。

2. 这样，实例化代码只用执行一次，后面再次访问时，判断if (singleton == null), 直接return实例化对象，也避免的反复进行方法同步.

3. 线程安全；延迟加载；效率较高

4. 结论：在实际开发中，推荐使用这种单例设计模式

本质是从懒汉模式上进化来的

静态内部类 （推荐）

静态内部类的特点

1. 当外面的类装载时，静态内部类是不会装载的
2. 当外面的类用到静态内部类时，静态内部类才会被装载，而且只装载一次
3. 类装载是线程安全的

public class Demo7 {
    public static void main(String[] args) {
        System.out.println("静态内部类,线程安全，效率也高，推荐");
        Singleton instance = Singleton.getInstance();
        Singleton instance2 = Singleton.getInstance();
        System.out.println(instance == instance2); // true
        System.out.println("instance.hashCode=" + instance.hashCode());
        System.out.println("instance2.hashCode=" + instance2.hashCode());
        
        //探究一个问题，执行下面这句话的时候，"Singleton 类初始化了"会不会输出？"SingletonInstance 类初始化了"会不会输出
        System.out.println(Singleton.name);
    }
}

class Singleton {
    
    static String name = "aaa";

    static {
        System.out.println("Singleton 类初始化了");
    }
    private Singleton() {}

    private static class SingletonInstance{
        static {
            System.out.println("SingletonInstance 类初始化了");
        }
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return SingletonInstance.INSTANCE;
    }
}

优缺点说明：

1） 这种方式采用了类装载的机制来保证初始化实例时只有一个线程

2） 静态内部类方式在Singleton类被装载时并不会立即实例化，而是在需要实例化时，调用getlnstance方法，才会装载Singletoninstance类，从而完成Singleton的实例化

3） 类的静态属性只会在第一次加载类的时候初始化，所以在这里，JVM帮助我们保证了线程的安全性，在类进行初始化时，别的线程是无法进入的。

4） 优点：避免了线程不安全，利用静态内部类特点实现延迟加载，效率高

5） 结论：推荐使用.

本质是从静态模式中进化来的

枚举 （推荐）

enum Singleton {
    INSTANCE;

    public void method() {
        System.out.println("这是方法");
    }
}

优缺点说明:

1） 这借助JDK1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，而且还能防止反序列化重新创建新的对象。

2） 这种方式是Effective Java作者Josh Bloch提倡的方式

3） 结论：推荐使用

JDK源码例子（Runtime）

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

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

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

优缺点

优点：

1）在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例

缺点：

1）在分布式系统中，存在多个JVM，就会有多个实例，违反了单例原则

2）因为是单例，所以假如该单例是有状态的，会导致多个应用该单例的线程出问题，因为单例模式必须得应用在无状态的场景下，比如作为工具类

简单工厂

• 不属于23种设计模式
• 为方便理解工厂及抽象工厂模式做铺垫

案例：

看一个披萨的项目：要便于披萨种类的扩展，要便于维护

1）披萨的种类很多（比如GreekPizz、 CheesePizz等）

2. 披萨的制作有prepare, bake, cut, box

3）完成披萨店订购功能。

传统方式类图：

传统方式优缺点：

1） 优点是比较好理解简单易操作。

2） 缺点是违反了设计模式的ocp原则，即对扩展开放，对修改关闭。即当我们给类增加新功能的时候，尽量不修改代码，或者尽可能少修改代码.

3） 比如我们这时要新增加一个Pizza的种类（Pepper披萨），我们需要做如下修改.1.新增一个Pepper类 2.修改OrderPizza类代码

4） 改进的思路分析 分析：修改代码可以接受，但是如果我们在其它的地方也有创建Pizza的代码，就意味 着,也需要修改，而创建Pizza的代码，往往有多处。 思路，把创建Pizza对象封装到一个类中，这样我们有新的Pizza种类时，只需要修改该 类就可，其它有创建到Pizza对象的代码就不需要修改了简单工厂模式

基本介绍

1） 简单工厂模式是属于创建型模式，是工厂模式的一种。简单工厂模式是由一 个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族 中最简单实用的模式

2） 简单工厂模式：定义了一个创建对象的类，由这个类来封装实例化对象的行为（代码）

3） 在软件开发中，当我们会用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式.

上面披萨店订购方案改进类图：

优缺点

优点:

1、工厂bai类含有必要的判断du逻辑，可以决zhi定在什么时候dao创建哪一个zhuan产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅“消费”产品；

2、简单工厂模式通过这种做法实现了对责任的分割，它提供了专门的工厂类用于创建对象。

3、客户端无须知道所创建的具体产品类的类名，只需要知道具体产品类所对应的参数即可，对于一些复杂的类名，通过简单工厂模式可以减少使用者的记忆量。

4、通过引入配置文件，可以在不修改任何客户端代码的情况下更换和增加新的具体产品类，在一定程度上提高了系统的灵活性。

缺点:

1、由于工厂类集中了所有产品创建逻辑，一旦不能正常工作，整个系统都要受到影响。

2、使用简单工厂模式将会增加系统中类的个数，在一定程序上增加了系统的复杂度和理解难度。

3、系统扩展困难，一旦添加新产品就不得不修改工厂逻辑，在产品类型较多时，有可能造成工厂逻辑过于复杂，不利于系统的扩展和维护。

4、简单工厂模式由于使用了静态工厂方法，造成工厂角色无法形成基于继承的等级结构。

5、违反开闭原则

工厂

案例：

和简单工厂模式的案例需求一模一样

基本介绍

定义了一个创建对象的抽象方法，由子类决定要实例化的类，工厂方 法模式将对象的实例化推迟到子类。

优缺点

优点：

工厂模式是简单工厂模式的进一步抽象和推广。它遵循了“开放—封闭”原则。

缺点：

1.工厂方法把简单工厂的内部逻辑判断转移到了客户端里来执行；每增加一产品就要增加一个产品工厂的类，增加了额外的开发量。

2.工厂和产品是一对一的关系，工厂只能生产某一个大类的产品，按照披萨的例子，工厂模式只能生产披萨

3.违反开闭原则

抽象工厂

案例

和工厂模式案例一样，但是新增了一个大类热狗

基本介绍

1） 抽象工厂模式：定义了一个interface用于创建相关或有依赖关系的对象簇，而无需 指明具体的类

2） 抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合。

3） 从设计层面看，抽象工厂模式就是对简单工厂模式的改进（或者称为进一步的抽象）。

4） 将工厂抽象成两层，AbsFactory（抽象工厂）和具体实现的工厂子类。程序员可以 根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇， 更利于代码的维护和扩展。

5）本质上是工厂模式的扩展，当抽象工厂模式只生产一类产品，那么就退化到工厂模式

优缺点

优点：

可以生产不同类别的产品

缺点：

和工厂模式一样，违反了开闭原则

工厂模式总结

1） 工厂模式的意义：将实例化对象的代码提取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦。从而提高项目的扩展和维护性。

2） 三种工厂模式（简单工厂模式、工厂方法模式、抽象工厂模式）

3） 设计模式的依赖抽象原则 ：

创建对象实例时，不要直接new类：而是把这个new类的动作放在一个工厂的方法中并返回。有的书上说，变量不要直接持有具体类的引用。

不要让类继承具体类，而是继承抽象类或者是实现interface（接口）

不要覆盖基类中已经实现的方法。

原型模式

案例

克隆羊问题：现在有一只羊tom,姓名为：tom,年龄为 1,颜色为：白色，请编写程序创建和tom羊属性完全相同的10只羊。

传统方式解决方案类图：

传统的方式的优缺点 :

1） 优点是比较好理解，简单易操作。

2） 库创建新的对象时，总是需要重新获取原始对象的属性，如果创建的对象比较复杂时，效率较低

3） 总是需要重新初始化对象，而不是动态地获得对象运行时的状态，不够灵活

4） 改进的思路分析

思路，Java中Object类是所有类的根类，Object类提供了一个clone()方法，该方法可以 将一个Java对象复制一份，但是需要实现done的Java类必须要实现一个接口Cloneable, 该接口表示该类能够复制且具有复制的能力=＞原型模式

原型模式基本介绍

1） 原型模式（ Prototype模式）是指：用原型实例指定创建对象的种类，并且通过拷贝这些原型，创建新的对象

2） 原型模式是一种创建型设计模式，允许一个对象再创建另外一个可定制的对象, 无需知道如何创建的细节

3） 工作原理是:通过将一个原型对象传给那个要发起创建的对象，这个要发起创建的对象通过请求原型对象拷贝它们自己来实施创建，即对象done()

JDK

//beans.xml
//bean 的scope 是原型模式，意味着创建bean实例时，每次创建都会产生一个新的实例
<bean id="suzy" class="com.zhenhunfan.design.pattern._03_prototype.jdk.Sheep" scope="prototype"/>

		ApplicationContext applicationContext = new ClassPathXmlApplicationContext("beans.xml");
        Object suzy1 = applicationContext.getBean("suzy");
        Object suzy2 = applicationContext.getBean("suzy");
        System.out.println(suzy1 == suzy2);   //false

其他例子:ArrayList（浅拷贝）

浅拷贝和深拷贝

浅拷贝基本介绍：

1） 对于数据类型是基本数据类型的成员变量，浅拷贝会直接进行值传递，也就是将该属性值复制一份给新的对象。

2） 对于数据类型是引用数据类型的成员变量，比如说成员变量是某个数组、某个类的对象等，那么浅拷贝会进行引用传递，也就是只是将该成员变量的引用值（内存地址）复制一份给新的对象。因为实际上两个对象的该成员变量都指向同一个 实例。在这种情况下，在一个对象中修改该成员变量会影响到另一个对象的该成员变量值

3） 前面我们克隆羊就是浅拷贝

4） 浅拷贝是使用默认的done。方法来实现 sheep = (Sheep)supen.clone() ;

深拷贝基本介绍：

1） 复制对象的所有基本数据类型的成员变量值

2） 为所有引用数据类型的成员变量申请存储空间，并复制每个引用数据类型成员变 量所弓用的对象，直到该对象可达的所有对象。也就是说，对象进行深拷贝要对 整个对象进行拷贝

深拷贝的实现方式:

1）重写done方法来实现深拷贝

2）通过对象序列化实现深拷贝 （不推荐，因为非常费CPU，需要解析流）

深拷贝 - 重写clone()

@Data
public class Sheep implements Cloneable {   //Cloneable接口没有方法，只是一个标记接口，假如没有实现该接口，调用clone()会报错
    String name;
    int age;
    String color;
    Sheep friend;
   
    public Sheep(String name, int age, String color, Sheep friend) {
        this.name = name;
        this.age = age;
        this.color = color;
        this.friend = friend;
    }

    public Sheep(Sheep sheep) throws CloneNotSupportedException {
        this.name = sheep.name;
        this.age = sheep.age;
        this.color = sheep.color;
        if(sheep.friend != null)
        this.friend = (Sheep) sheep.friend.clone();
    }

    @Override
    public String toString() {
        return "Sheep{" +
                "name='" + name + '\'' +
                ", age=" + age +
                ", color='" + color + '\'' +
                '}';
    }

    @Override
    protected Object clone() throws CloneNotSupportedException {
        return new Sheep(this);
    }
}

深拷贝 - 序列化实现：

public class CloneUtils {
    @SuppressWarnings("unchecked")
    public static <T extends Serializable> T clone(T object) { //Serializable接口也是个标记接口
        T cloneObj = null;
        try {
            ByteArrayOutputStream out = new ByteArrayOutputStream();
            ObjectOutputStream obs = new ObjectOutputStream(out);
            obs.writeObject(object);
            obs.close();

            ByteArrayInputStream ios = new ByteArrayInputStream(out.toByteArray());
            ObjectInputStream ois = new ObjectInputStream(ios);
            cloneObj = (T) ois.readObject();
        } catch (Exception e) {
            e.printStackTrace();
        }
        return cloneObj;
    }
}

建造者模式（生成器模式）

案例：

盖房项目需求

1） 房子的内部属性（该属性是个对象）有很多，有地基、墙、屋顶等等，

2） 建造房子是有顺序的，得先打桩、再砌墙、最后封顶

3） 最后通过复杂的建设，创建出一个房子对象

传统方式解决该问题的思路：通过构造函数的方式创建房子对象

传统方式解决盖房需求问题的优缺点分析:

1） 优点：比较好理解，简单易操作。

2） 缺点：设计的程序结构，过于简单，没有设计缓存层对象，程序的扩展性和维护性不好，比方说这个时候房子要带院子，有地下车库，就要改构造函数；也就是说，这种设计方案，把产品（即：房子）和创建产品的过程（即：建房子流程）封装在一起，耦合性增强了。

3） 解决方案；将产品和产品建造过程解耦=> 建造者模式

基本介绍

1） 建造者模式（ BuilderPattern） 又叫生成器模式，是一种对象构建模式。

为了构建一个复杂对象，将复杂对象的每个对象属性的建造过程抽象出来（抽象类别），
最终按照一定的顺序构建出这个复杂对象

2） 建造者模式是一步一步创建复杂的对象的属性对象，从而最终构建出该复杂都西昂，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。

建造者模式的四个角色：

1） Product （产品角色）：一个具体的产品对象。

2） Builder （抽象建造者）：创建一个Product对象的各个部件指定的接口。

3） ConcreteBuilder （具体建造者）:实现接口，构建和装配各个部件。

4） Director （指挥者）:构建一个使用Builder接口的对象。它主要是用于创建一个复杂的对象。它主要有两个作用，一是：隔离了客户与对象的生产过程，二是: 负责控制产品对象的生产过程（先创建哪一属性，再创建哪一属性）。

建造者模式原理类图：

适用场景

需要创建复杂对象的时候，该复杂对象有很多复杂属性，有些属性是必须的，有些属性是不必须的，还可能属性间有依赖关系

结构型模式

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

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

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

1. 代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。
2. 适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。
3. 桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。
4. 装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。
5. 外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。
6. 享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。
7. 组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。

适配器（Adapter）模式

基本介绍

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

1.简单的比喻就是电源适配器，我们的手机是直流电，家用电是交流电，插头就是一个适配器，把交流电转换成手机能用的直流电

2.适配器模式的特点是不修改原有的接口或类

适配器模式原理类图1：

适配器模式实现方式有对象模式（组合或聚合）和类模式（继承）

推荐使用对象模式，类模式把原始接口或类的方法暴露给客户端，违反了迪米特原则（最少知道原则）

案例1

有人耳聋听不到，通过适配器中转

public class Demo1 {
    /**
     * 充当客户端角色
     * @param args
     */
    public static void main(String[] args) {
        Translator translator = new Adapter(new Speaker());
        System.out.println(translator.translate());
    }
}

/**
 * 原有的类或接口
 */
class Speaker {
    public String speak() {
        return "China No.l";
    }
}

/**
 * 适配器接口
 */
interface Translator {
    String translate();
}

/**
 * 具体的适配器
 */
class Adapter implements Translator {
    private Speaker speaker;
    public Adapter(Speaker speaker) {
        this.speaker = speaker;
    }

    public String translate() {
        String result = speaker.speak();
        //...理解、手语话
        return result;
    }
}

JDK & Spring源码中的应用

JDK： 
java.util.Arrays#asList() 
java.util.Collections#list() 

Spring: 
org.springframework.context.event.GenericApplicationListenerAdapter

桥接模式

基本介绍

出现背景：

在现实生活中，某些类具有两个或多个维度的变化，如图形既可按形状分，又可按颜色分。如何设计类似于 Photoshop 这样的软件，能画不同形状和不同颜色的图形呢？如果用继承方式，m 种形状和 n 种颜色的图形就有 m×n 种，不但对应的子类很多，而且扩展困难。

当然，这样的例子还有很多，如不同颜色和字体的文字、不同品牌和功率的汽车、不同性别和职业的男女、支持不同平台和不同文件格式的媒体播放器等。如果用桥接模式就能很好地解决这些问题。

定义：

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

优点：

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

缺点：

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

原理类图：

桥接（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);
        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 {
    protected RefinedAbstraction(Implementor imple) {
        super(imple);
    }
    public void Operation() {
        System.out.println("扩展抽象化(Refined Abstraction)角色被访问");
        imple.OperationImpl();
    }
}

应用场景：

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

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

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

很多时候，我们分不清该使用继承还是组合/聚合或其他方式等，其实可以从现实语义进行思考。因为软件最终还是提供给现实生活中的人使用的，是服务于人类社会的，软件是具备现实场景的。当我们从纯代码角度无法看清问题时，现实角度可能会提供更加开阔的思路。

案例

女士买包：女士皮包有很多种，可以按用途分、按皮质分、按品牌分、按颜色分、按大小分等，存在多个维度的变化，所以采用桥接模式来实现女士皮包的选购比较合适。

本实例按用途分可选钱包（Wallet）和挎包（HandBag），按颜色分可选黄色（Yellow）和红色（Red）。可以按两个维度定义为颜色类和包类。

public class Demo2 {
    public static void main(String[] args) {
        //女士买个红色的挎包
        Red red = new Red();
        HandBag handBag = new HandBag();
        handBag.setColor(red);

        System.out.println("买了一个"+handBag.getName());
    }
}

//实现化角色：颜色
interface Color {
    String getColor();
}
//具体实现化角色：黄色
class Yellow implements Color {
    public String getColor() {
        return "yellow";
    }
}
//具体实现化角色：红色
class Red implements Color {
    public String getColor() {
        return "red";
    }
}
//抽象化角色：包
abstract class Bag {
    protected Color color;
    public void setColor(Color color) {
        this.color = color;
    }
    public abstract String getName();
}
//扩展抽象化角色：挎包
class HandBag extends Bag {
    public String getName() {
        return color.getColor() + "HandBag";
    }
}
//扩展抽象化角色：钱包
class Wallet extends Bag {
    public String getName() {
        return color.getColor() + "Wallet";
    }
}

装饰器模式

基本介绍

定义：

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

优点有：

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

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

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

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

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

装饰器模式原理类图：

案例

孩子穿衣服，只能穿内衣内裤，爸爸帮忙穿裤子，妈妈帮忙穿上衣

public class Demo2 {
    public static void main(String[] args) {
        Dress dress = new Mom(new Dad(new Child()));
        dress.dress();

        dress = new Dad(new Mom(new Child()));
        dress.dress();
    }
}

/**
 * 穿衣服接口，抽象构件角色
 */
interface Dress {
    void dress();
}

/**
 * 孩子类，会自己穿衣服，但只穿了内衣内裤，具体构件角色
 */
class Child implements Dress {

    public void dress() {
        System.out.println("孩子穿了内衣和内裤");
    }
}

/**
 * 穿其他衣服的类，抽象装饰
 */
abstract class Decorator implements Dress {
    private Dress dress;

    public Decorator(Dress dress) {
        this.dress = dress;
    }

    public void dress() {
        dress.dress();
    }
}

/**
 * 爸爸类，帮忙穿裤子，具体装饰角色
 */
class Dad extends Decorator{

    public Dad(Dress dress) {
        super(dress);
    }

    public void dress() {
        super.dress();
        System.out.println("爸爸帮忙穿裤子");
    }
}

/**
 * 妈妈类，帮忙穿上衣，具体装饰角色
 */
class Mom extends Decorator{

    public Mom(Dress dress) {
        super(dress);
    }

    public void dress() {
        super.dress();
        System.out.println("妈妈帮忙穿上衣");
    }
}

JDK 源码中的应用

装饰器模式通常在以下几种情况使用:

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

装饰器模式在 Java 语言中的最著名的应用莫过于 Java I/O 标准库的设计了。例如，InputStream 的子类 FilterInputStream，OutputStream 的子类 FilterOutputStream，Reader 的子类 BufferedReader 以及 FilterReader，还有 Writer 的子类 BufferedWriter、FilterWriter 以及 PrintWriter 等，它们都是抽象装饰类。

下面代码是为 FileReader 增加缓冲区而采用的装饰类 BufferedReader 的例子：

BufferedReader in = new BufferedReader(new FileReader("filename.txt"));
String s = in.readLine();

组合模式

基本介绍

定义：

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

优点：

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

缺点：

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

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

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

组合模式分为透明式的组合模式和安全式的组合模式。

透明方式

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

透明方式类图：

安全方式

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

安全方式类图：

案例

人口统计：全国有33个省组成，每个省有多个市组成，每个市自己计算人口

public class Demo3 {
    public static void main(String[] args) {
        Country china = new Country("China");

        Province zhejiang = new Province("浙江省");

        City hangzhou = new City("杭州",100);
        City ningbo = new City("宁波",200);

        china.add(zhejiang);
        zhejiang.add(hangzhou);
        zhejiang.add(ningbo);

        System.out.println("全国人口总数为："+china.calculate());
    }
}

interface Calculate{
    int calculate();
}

//国家
class Country implements Calculate{
    String name;
    private ArrayList<Calculate> children = new ArrayList<Calculate>();

    public Country(String name) {
        this.name = name;
    }

    public void add(Calculate c) {
        children.add(c);
    }
    public void remove(Calculate c) {
        children.remove(c);
    }
    public Calculate getChild(int i) {
        return children.get(i);
    }

    public int calculate() {
        int result = 0;
        for (Calculate obj : children) {
            result += obj.calculate();
        }
        return result;
    }
}

//省份
class Province implements Calculate{
    String name;
    private ArrayList<Calculate> children = new ArrayList<Calculate>();

    public Province(String name) {
        this.name = name;
    }

    public void add(Calculate c) {
        children.add(c);
    }
    public void remove(Calculate c) {
        children.remove(c);
    }
    public Calculate getChild(int i) {
        return children.get(i);
    }

    public int calculate() {
        int result = 0;
        for (Calculate obj : children) {
            result += obj.calculate();
        }
        return result;
    }
}

//市
class City implements Calculate{
    String name;
    private ArrayList<Calculate> children = new ArrayList<Calculate>();
    private int Count;

    public City(String name, int count) {
        this.name = name;
        Count = count;
    }
    public int calculate() {
        return Count;
    }
}

外观模式

基本介绍

在现实生活中，常常存在办事较复杂的例子，如办房产证或注册一家公司，有时要同多个部门联系，这时要是有一个综合部门能解决一切手续问题就好了。

软件设计也是这样，当一个系统的功能越来越强，子系统会越来越多，客户对系统的访问也变得越来越复杂。这时如果系统内部发生改变，客户端也要跟着改变，这违背了“开闭原则”，也违背了“迪米特法则”，所以有必要为多个子系统提供一个统一的接口，从而降低系统的耦合度，这就是外观模式的目标。

图 1 给出了客户去当地房产局办理房产证过户要遇到的相关部门。

外观模式的定义与特点

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

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

外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点。

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

外观（Facade）模式的主要缺点如下。

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

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

外观模式原理类图：

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

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

框架案例

1.tomcat里的RequestFacade

享元模式

基本介绍

在面向对象程序设计过程中，有时会面临要创建大量相同或相似对象实例的问题。创建那么多的对象将会耗费很多的系统资源，它是系统性能提高的一个瓶颈。

例如，围棋和五子棋中的黑白棋子，图像中的坐标点或颜色，局域网中的路由器、交换机和集线器，教室里的桌子和凳子等。这些对象有很多相似的地方，如果能把它们相同的部分提取出来共享，则能节省大量的系统资源，这就是享元模式的产生背景。

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

享元模式的主要优点是：相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。

其主要缺点是：

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

享元模式的定义提出了两个要求，细粒度和共享对象。因为要求细粒度，所以不可避免地会使对象数量多且性质相近，此时我们就将这些对象的信息分为两个部分：内部状态和外部状态。

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

比如，连接池中的连接对象，保存在连接对象中的用户名、密码、连接URL等信息，在创建对象的时候就设置好了，不会随环境的改变而改变，这些为内部状态。而当每个连接要被回收利用时，我们需要将它标记为可用状态，这些为外部状态。

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

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

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

享元模式原理类图：

• UnsharedConcreteFlyweight 是非享元角色，里面包含了非共享的外部状态信息 info；
• Flyweight 是抽象享元角色，里面包含了享元方法 operation(UnsharedConcreteFlyweight state)，非享元的外部状态以参数的形式通过该方法传入；
• ConcreteFlyweight 是具体享元角色，包含了关键字 key，它实现了抽象享元接口；
• FlyweightFactory 是享元工厂角色，它是关键字 key 来管理具体享元；
• 客户角色通过享元工厂获取具体享元，并访问具体享元的相关方法。

案例

森林里种树，因为森林里的树有很多，所以不可能每个树都是一个独立的对象，要不然内存爆炸了，所以运用享元模式，树的坐标做为外部数据

public class Demo2 {
    public static void main(String[] args) {
        TreeFactory factory = new TreeFactory();
        Plant f01 = factory.getFlyweight("a");
        Plant f02 = factory.getFlyweight("a");
        Plant f03 = factory.getFlyweight("a");
        Plant f11 = factory.getFlyweight("b");
        Plant f12 = factory.getFlyweight("b");
        f01.planting_tree(new TreeNode(1,2));
        f02.planting_tree(new TreeNode(2,3));
        f03.planting_tree(new TreeNode(3,4));
        f11.planting_tree(new TreeNode(4,5));
        f12.planting_tree(new TreeNode(5,6));
    }
}

//非享元角色,树的坐标，外部状态
class TreeNode {
    private int x ;
    private int y ;

    public TreeNode(int x, int y) {
        this.x = x;
        this.y = y;
    }

    public int getX() {
        return x;
    }

    public void setX(int x) {
        this.x = x;
    }

    public int getY() {
        return y;
    }

    public void setY(int y) {
        this.y = y;
    }
}

//抽象享元角色,种树接口
interface Plant {
    public void planting_tree(TreeNode treeNode);
}

//具体享元角色
class Tree implements Plant {
    //树的名字
    String name;

    public Tree(String name) {
        this.name = name;
    }

    public void planting_tree(TreeNode treeNode) {
        System.out.println(String.format("tree %s 种在了%d %d",name,treeNode.getX(),treeNode.getY()));
    }
}

//享元工厂角色，树工厂
class TreeFactory {
    private HashMap<String, Plant> flyweights = new HashMap<String, Plant>();

    public Plant getFlyweight(String key) {
        Plant flyweight = flyweights.get(key);
        if (flyweight != null) {
            System.out.println("具体享元" + key + "已经存在，被成功获取！");
        } else {
            flyweight = new Tree(key);
            flyweights.put(key, flyweight);
        }
        return flyweight;
    }
}

代理模式

基本介绍

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

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

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

代理模式的主要优点有：

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

其主要缺点是：

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

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

代理模式原理类图：

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

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

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

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

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

前面分析了代理模式的结构与特点，现在来分析以下的应用场景。

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

在前面介绍的代理模式中，代理类中包含了对真实主题的引用，这种方式存在两个缺点。

1. 真实主题与代理主题一一对应，增加真实主题也要增加代理。
2. 设计代理以前真实主题必须事先存在，不太灵活。采用动态代理模式可以解决以上问题，如 SpringAOP，其结构图如图 4 所示。

动态代理用的是反射吗？

案例

房产中介，二手房购房者不能直接联系到房东，通过中介找房，中介就可以在中间哄抬价格

public class Demo2 {
    public static void main(String[] args) {
        HouseProxy houseProxy = new HouseProxy();
        System.out.println("买房人收到报价："+houseProxy.offer());
    }
}

//出价接口，抽象主题
interface Offer{
    int offer();
}
//房子的主人
class HouseHolder implements Offer{

    public int offer() {
        return 50;
    }
}

class HouseProxy implements Offer{
    private HouseHolder houseHolder;

    public HouseProxy() {
        this.houseHolder = new HouseHolder();
    }

    public int offer() {
        System.out.println("房子房主出价是："+houseHolder.offer()+",这个我们不会告知买房人");
        System.out.println("我们告诉买房人的价格是翻一番："+houseHolder.offer()*2);
        return houseHolder.offer()*2;
    }
}

行为型模式

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

行为型模式是 GoF 设计模式中最为庞大的一类，它包含以下 11 种模式。

1. 模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。
2. 策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。
3. 命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。
4. 职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。
5. 状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。
6. 观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。
7. 中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。
8. 迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。
9. 访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。
10. 备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。
11. 解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

以上 11 种行为型模式，除了模板方法模式和解释器模式是类行为型模式，其他的全部属于对象行为型模式

模板方法模式

基本介绍

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

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

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

该模式的主要优点如下。

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

该模式的主要缺点如下。

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

原理类图：

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

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

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

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

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

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

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

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

模板方法模式通常适用于以下场景。

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

Java Web种的案例

1.典型案例：Servlet，我们都会重写doGet或doPost等方法，Servlet种的模板方法是services()方法

策略模式

基本介绍

在现实生活中常常遇到实现某种目标存在多种策略可供选择的情况，例如，出行旅游可以乘坐飞机、乘坐火车、骑自行车或自己开私家车等，超市促销可以釆用打折、送商品、送积分等方法。

在软件开发中也常常遇到类似的情况，当实现某一个功能存在多种算法或者策略，我们可以根据环境或者条件的不同选择不同的算法或者策略来完成该功能，如数据排序策略有冒泡排序、选择排序、插入排序、二叉树排序等。

如果使用多重条件转移语句实现（即硬编码），不但使条件语句变得很复杂，而且增加、删除或更换算法要修改原代码，不易维护，违背开闭原则。如果采用策略模式就能很好解决该问题。

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

策略模式的主要优点如下。

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

其主要缺点如下。

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

原理类图：

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

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

策略模式在很多地方用到，如 Java SE 中的容器布局管理就是一个典型的实例，Java SE 中的每个容器都存在多种布局供用户选择。在程序设计中，通常在以下几种情况中使用策略模式较多。

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

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

JDK中的应用

List的Comparable 类，进行不同的排序

命令模式

基本介绍

在软件开发系统中，“方法的请求者”与“方法的实现者”之间经常存在紧密的耦合关系，这不利于软件功能的扩展与维护。例如，想对方法进行“撤销、重做、记录”等处理都很不方便，因此“如何将方法的请求者与实现者解耦？”变得很重要，命令模式就能很好地解决这个问题。

在现实生活中，命令模式的例子也很多。比如看电视时，我们只需要轻轻一按遥控器就能完成频道的切换，这就是命令模式，将换台请求和换台处理完全解耦了。电视机遥控器（命令发送者）通过按钮（具体命令）来遥控电视机（命令接收者）。

再比如，我们去餐厅吃饭，菜单不是等到客人来了之后才定制的，而是已经预先配置好的。这样，客人来了就只需要点菜，而不是任由客人临时定制。餐厅提供的菜单就相当于把请求和处理进行了解耦，这就是命令模式的体现。

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

命令模式的主要优点如下。

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

其缺点是：

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

原理类图：

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

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

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

命令模式通常适用于以下场景。

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

命令模式的扩展

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

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

职责链（责任链）模式

基本介绍

在现实生活中，一个事件需要经过多个对象处理是很常见的场景。例如，采购审批流程、请假流程等。公司员工请假，可批假的领导有部门负责人、副总经理、总经理等，但每个领导能批准的天数不同，员工必须根据需要请假的天数去找不同的领导签名，也就是说员工必须记住每个领导的姓名、电话和地址等信息，这无疑增加了难度。

在计算机软硬件中也有相关例子，如总线网中数据报传送，每台计算机根据目标地址是否同自己的地址相同来决定是否接收；还有异常处理中，处理程序根据异常的类型决定自己是否处理该异常；还有 Struts2 的拦截器、JSP 和 Servlet 的 Filter 等，所有这些，都可以考虑使用责任链模式来实现。

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

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

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

责任链模式是一种对象行为型模式，其主要优点如下。

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

其主要缺点如下。

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

原理类图：

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

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

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

应用场景

责任链模式通常在以下几种情况使用。

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

模式的扩展

职责链模式存在以下两种情况。

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

责任链模式和建造者模式合用，请求对象可以用建造者模式创建

状态模式

基本介绍

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

对这种有状态的对象编程，传统的解决方案是：将这些所有可能发生的情况全都考虑到，然后使用 if-else 或 switch-case 语句来做状态判断，再进行不同情况的处理。但是显然这种做法对复杂的状态判断存在天然弊端，条件判断语句会过于臃肿，可读性差，且不具备扩展性，维护难度也大。且增加新的状态时要添加新的 if-else 语句，这违背了“开闭原则”，不利于程序的扩展。

以上问题如果采用“状态模式”就能很好地得到解决。状态模式的解决思想是：当控制一个对象状态转换的条件表达式过于复杂时，把相关“判断逻辑”提取出来，用各个不同的类进行表示，系统处于哪种情况，直接使用相应的状态类对象进行处理，这样能把原来复杂的逻辑判断简单化，消除了 if-else、switch-case 等冗余语句，代码更有层次性，并且具备良好的扩展力。

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

状态模式是一种对象行为型模式，其主要优点如下。

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

状态模式的主要缺点如下。

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

原理类图：

通常在以下情况下可以考虑使用状态模式。

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

状态模式的扩展

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

观察者模式

基本介绍

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

在软件世界也是这样，例如，Excel 中的数据与折线图、饼状图、柱状图之间的关系；MVC 模式中的模型与视图的关系；事件模型中的事件源与事件处理者。所有这些，如果用观察者模式来实现就非常方便。

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

观察者模式是一种对象行为型模式，其主要优点如下。

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

它的主要缺点如下。

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

原理类图：

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

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

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

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

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

模式的扩展

在 Java 中，通过 java.util.Observable 类和 java.util.Observer 接口定义了观察者模式，只要实现它们的子类就可以编写观察者模式实例。

1. Observable类

Observable 类是抽象目标类，它有一个 Vector 向量，用于保存所有要通知的观察者对象，下面来介绍它最重要的 3 个方法。

1. void addObserver(Observer o) 方法：用于将新的观察者对象添加到向量中。

2. void notifyObservers(Object arg) 方法：调用向量中的所有观察者对象的 update() 方法，通知它们数据发生改变。通常越晚加入向量的观察者越先得到通知。

3. void setChange() 方法：用来设置一个 boolean 类型的内部标志位，注明目标对象发生了变化。当它为真时，notifyObservers() 才会通知观察者。

4. Observer 接口

Observer 接口是抽象观察者，它监视目标对象的变化，当目标对象发生变化时，观察者得到通知，并调用 void update(Observable o,Object arg) 方法，进行相应的工作。

中介者模式

基本介绍

出现背景

在现实生活中，常常会出现好多对象之间存在复杂的交互关系，这种交互关系常常是“网状结构”，它要求每个对象都必须知道它需要交互的对象。例如，每个人必须记住他（她）所有朋友的电话；而且，朋友中如果有人的电话修改了，他（她）必须让其他所有的朋友一起修改，这叫作“牵一发而动全身”，非常复杂。

如果把这种“网状结构”改为“星形结构”的话，将大大降低它们之间的“耦合性”，这时只要找一个“中介者”就可以了。如前面所说的“每个人必须记住所有朋友电话”的问题，只要在网上建立一个每个朋友都可以访问的“通信录”就解决了。这样的例子还有很多，例如，你刚刚参加工作想租房，可以找“房屋中介”；或者，自己刚刚到一个陌生城市找工作，可以找“人才交流中心”帮忙。

在软件的开发过程中，这样的例子也很多，例如，在 MVC 框架中，控制器（C）就是模型（M）和视图（V）的中介者；还有大家常用的 QQ 聊天程序的“中介者”是 QQ 服务器。所有这些，都可以采用“中介者模式”来实现，它将大大降低对象之间的耦合性，提高系统的灵活性。

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

中介者模式是一种对象行为型模式，其主要优点如下。

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

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

原理类图:

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

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

应用场景

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

模式扩展

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

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

迭代器模式

基本介绍

出现背景

在现实生活以及程序设计中，经常要访问一个聚合对象中的各个元素，如“数据结构”中的链表遍历，通常的做法是将链表的创建和遍历都放在同一个类中，但这种方式不利于程序的扩展，如果要更换遍历方法就必须修改程序源代码，这违背了 “开闭原则”。

既然将遍历方法封装在聚合类中不可取，那么聚合类中不提供遍历方法，将遍历方法由用户自己实现是否可行呢？答案是同样不可取，因为这种方式会存在两个缺点：

1. 暴露了聚合类的内部表示，使其数据不安全；
2. 增加了客户的负担。

“迭代器模式”能较好地克服以上缺点，它在客户访问类与聚合类之间插入一个迭代器，这分离了聚合对象与其遍历行为，对客户也隐藏了其内部细节，且满足“单一职责原则”和“开闭原则”，如 Java 中的 Collection、List、Set、Map 等都包含了迭代器。

迭代器模式在生活中应用的比较广泛，比如：物流系统中的传送带，不管传送的是什么物品，都会被打包成一个个箱子，并且有一个统一的二维码。这样我们不需要关心箱子里是什么，在分发时只需要一个个检查发送的目的地即可。再比如，我们平时乘坐交通工具，都是统一刷卡或者刷脸进站，而不需要关心是男性还是女性、是残疾人还是正常人等信息。

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

迭代器模式是一种对象行为型模式，其主要优点如下。

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

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

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

原理类图

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

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

应用场景

迭代器模式通常在以下几种情况使用。

1. 当需要为聚合对象提供多种遍历方式时。
2. 当需要为遍历不同的聚合结构提供一个统一的接口时。
3. 当访问一个聚合对象的内容而无须暴露其内部细节的表示时。

由于聚合与迭代器的关系非常密切，所以大多数语言在实现聚合类时都提供了迭代器类，因此大数情况下使用语言中已有的聚合类的迭代器就已经够了。

模式扩展

迭代器模式常常与组合模式结合起来使用，在对组合模式中的容器构件进行访问时，经常将迭代器潜藏在组合模式的容器构成类中。

访问者模式

基本介绍

出现背景

在现实生活中，有些集合对象存在多种不同的元素，且每种元素也存在多种不同的访问者和处理方式。例如，公园中存在多个景点，也存在多个游客，不同的游客对同一个景点的评价可能不同；医院医生开的处方单中包含多种药元素，査看它的划价员和药房工作人员对它的处理方式也不同，划价员根据处方单上面的药品名和数量进行划价，药房工作人员根据处方单的内容进行抓药。

这样的例子还有很多，例如，电影或电视剧中的人物角色，不同的观众对他们的评价也不同；还有顾客在商场购物时放在“购物车”中的商品，顾客主要关心所选商品的性价比，而收银员关心的是商品的价格和数量。

这些被处理的数据元素相对稳定而访问方式多种多样的数据结构，如果用“访问者模式”来处理比较方便。访问者模式能把处理方法从数据结构中分离出来，并可以根据需要增加新的处理方法，且不用修改原来的程序代码与数据结构，这提高了程序的扩展性和灵活性。

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

访问者（Visitor）模式是一种对象行为型模式，其主要优点如下。

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

访问者（Visitor）模式的主要缺点如下。

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

原理类图：

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

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

应用场景

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

简而言之，就是当对集合中的不同类型数据（类型数量稳定）进行多种操作时，使用访问者模式。

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

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

模式的扩展

访问者（Visitor）模式是使用频率较高的一种设计模式，它常常同以下两种设计模式联用。

(1)与“迭代器模式”联用。因为访问者模式中的“对象结构”是一个包含元素角色的容器，当访问者遍历容器中的所有元素时，常常要用迭代器。如【例1】中的对象结构是用 List 实现的，它通过 List 对象的 Iterator() 方法获取迭代器。如果对象结构中的聚合类没有提供迭代器，也可以用迭代器模式自定义一个。

(2)访问者（Visitor）模式同“组合模式”联用。因为访问者（Visitor）模式中的“元素对象”可能是叶子对象或者是容器对象，如果元素对象包含容器对象，就必须用到组合模式

备忘录模式

基本介绍

每个人都有犯错误的时候，都希望有种“后悔药”能弥补自己的过失，让自己重新开始，但现实是残酷的。在计算机应用中，客户同样会常常犯错误，能否提供“后悔药”给他们呢？当然是可以的，而且是有必要的。这个功能由“备忘录模式”来实现。

其实很多应用软件都提供了这项功能，如 Word、记事本、Photoshop、Eclipse 等软件在编辑时按 Ctrl+Z 组合键时能撤销当前操作，使文档恢复到之前的状态；还有在 IE 中的后退键、数据库事务管理中的回滚操作、玩游戏时的中间结果存档功能、数据库与操作系统的备份操作、棋类游戏中的悔棋功能等都属于这类。

备忘录模式能记录一个对象的内部状态，当用户后悔时能撤销当前操作，使数据恢复到它原先的状态。

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

备忘录模式是一种对象行为型模式，其主要优点如下。

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

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

原理类图

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

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

应用场景

1. 需要保存与恢复数据的场景，如玩游戏时的中间结果的存档功能。
2. 需要提供一个可回滚操作的场景，如 Word、记事本、Photoshop，Eclipse 等软件在编辑时按 Ctrl+Z 组合键，还有数据库中事务操作。

模式的扩展

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

Spring Webflow中的应用

由于 JDK、Spring、Mybatis中很少有备忘录模式，所以该设计模式不做典型应用源码分析。

Spring Webflow 中 DefaultMessageContext 类实现了 StateManageableMessageContext 接口，查看其源码可以发现其主要逻辑就相当于给 Message 备份。

解释器模式

基本介绍

出现背景

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

虽然使用解释器模式的实例不是很多，但对于满足以上特点，且对运行效率要求不是很高的应用实例，如果用解释器模式来实现，其效果是非常好的

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

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

解释器模式是一种类行为型模式，其主要优点如下。

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

解释器模式的主要缺点如下。

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

解释器模式常用于对简单语言的编译或分析实例中，为了掌握好它的结构与实现，必须先了解编译原理中的“文法、句子、语法树”等相关概念。

1) 文法

文法是用于描述语言的语法结构的形式规则。没有规矩不成方圆，例如，有些人认为完美爱情的准则是“相互吸引、感情专一、任何一方都没有恋爱经历”，虽然最后一条准则较苛刻，但任何事情都要有规则，语言也一样，不管它是机器语言还是自然语言，都有它自己的文法规则。例如，中文中的“句子”的文法如下。

〈句子〉::=〈主语〉〈谓语〉〈宾语〉
〈主语〉::=〈代词〉|〈名词〉
〈谓语〉::=〈动词〉
〈宾语〉::=〈代词〉|〈名词〉
〈代词〉你|我|他
〈名词〉7大学生I筱霞I英语
〈动词〉::=是|学习

注：这里的符号“::=”表示“定义为”的意思，用“〈”和“〉”括住的是非终结符，没有括住的是终结符。

2) 句子

句子是语言的基本单位，是语言集中的一个元素，它由终结符构成，能由“文法”推导出。例如，上述文法可以推出“我是大学生”，所以它是句子。

3) 语法树

语法树是句子结构的一种树型表示，它代表了句子的推导结果，它有利于理解句子语法结构的层次。

句子“我是大学生”的语法树:

解释器模式的结构与组合模式相似，不过其包含的组成元素比组合模式多，而且组合模式是对象结构型模式，而解释器模式是类行为型模式。解释器模式的结构与组合模式相似，不过其包含的组成元素比组合模式多，而且组合模式是对象结构型模式，而解释器模式是类行为型模式。

原理类图：

解释器模式包含以下主要角色。

1. 抽象表达式（Abstract Expression）角色：定义解释器的接口，约定解释器的解释操作，主要包含解释方法 interpret()。
2. 终结符表达式（Terminal Expression）角色：是抽象表达式的子类，用来实现文法中与终结符相关的操作，文法中的每一个终结符都有一个具体终结表达式与之相对应。
3. 非终结符表达式（Nonterminal Expression）角色：也是抽象表达式的子类，用来实现文法中与非终结符相关的操作，文法中的每条规则都对应于一个非终结符表达式。
4. 环境（Context）角色：通常包含各个解释器需要的数据或是公共的功能，一般用来传递被所有解释器共享的数据，后面的解释器可以从这里获取这些值。
5. 客户端（Client）：主要任务是将需要分析的句子或表达式转换成使用解释器对象描述的抽象语法树，然后调用解释器的解释方法，当然也可以通过环境角色间接访问解释器的解释方法。

应用场景

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

注意：解释器模式在实际的软件开发中使用比较少，因为它会引起效率、性能以及维护等问题。如果碰到对表达式的解释，在 Java 中可以用 Expression4J 或 Jep 等来设计。

模式的扩展

在项目开发中，如果要对数据表达式进行分析与计算，无须再用解释器模式进行设计了，Java 提供了以下强大的数学公式解析器：Expression4J、MESP(Math Expression String Parser) 和 Jep 等，它们可以解释一些复杂的文法，功能强大，使用简单。

现在以 Jep 为例来介绍该工具包的使用方法。Jep 是 Java expression parser 的简称，即 Java 表达式分析器，它是一个用来转换和计算数学表达式的 Java 库。通过这个程序库，用户可以以字符串的形式输入一个任意的公式，然后快速地计算出其结果。而且 Jep 支持用户自定义变量、常量和函数，它包括许多常用的数学函数和常量。

使用前先下载 Jep 压缩包，解压后，将 jep-x.x.x.jar 文件移到选择的目录中，在 Eclipse 的“Java 构建路径”对话框的“库”选项卡中选择“添加外部 JAR(X)...”，将该 Jep 包添加项目中后即可使用其中的类库。

总结

分类	设计模式	简述	一句话归纳	目的	生活案例
创建型设计模式 （简单来说就是用来创建对象的）	工厂模式（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）	允许对象组合实现与继承相同的代码重用，负责任务的调用和分配	这个需求很简单，怎么实现我不管	只对结果负责	授权委托书

PS：参考了设计模式