设计模式面试题（设计模式速成版）

说明

该文章适用于之前学习过设计模式，但是基本忘了。使用该文章进行快速回忆。因为是应付面试（不是笔试），所以该文结合了自己的理解，使用大白话来解释各个模型，如有错误或不严谨的地方，欢迎在评论区指正。

若之前没有学习过设计模式，可以将该文章死记硬背，然后应付面试。

设计模式详细学习，可以参见 http://c.biancheng.net/view/1317.html

名词解释

• 设计模式：软件设计模式是对各种面向对象方法的一种总结。前辈们遇到了好多设计问题，然后利用面向对象解决了。然后他们把解决方案汇总起来，形成了20多种设计模式。它可以有效的帮助我们利用面向对象，来提高代码的复用性、扩展性等。 设计模式包含4个关键元素：

  • 模式名称：就是设计模式的名字。
  • 问题：就是当面对什么样的设计问题时，应该采用该设计模式。即该设计模式的应用场景
  • 解决方案：该设计模式是使用什么样的方案解决的。
  • 效果：最后解决后，效果怎么样。比如扩展性怎么样，复用性怎么样。优缺点等等

• 组合：将多个种类的对象组合成一个新的对象。如 显示器 + 键盘 + 鼠标 +主机 = 电脑。

• 聚合：将多个同种对象聚起来，形成一个新的对象，如 50个学生 = 一个班级

• 用户：在设计模式中，用户并不是指具体使用系统的用户，而是使用你代码，或者是扩展你代码的其他程序员。

UML基础

UML主要用于表示类与类之间的关系。例如：

如图，在该图中

该图表示类，其中 Rectangle为类名。 length:double为 属性:类型。getArea():double 为 方法:返回值

圆圈代表接口，getArea():double为该接口的方法

虚线箭头表示实现，用于表示类实现了这个接口。

如果为实线，则为继承。

这个表示依赖。可以简单的理解为左边的类用到了右边的类。

这个是聚合，如果这个菱形为实心的，则为组合。

面向对象编程中，都有哪些设计原则

开闭原则

对扩展开放，对修改关闭。就是如果要修改原有的功能或者是扩展功能，尽量去扩展原有的代码，而不是修改原来已有的代码。

里氏替换原则（Liskov Substitution Principle）

任何子类对象都应该可以替换其派生的超类对象 。即，子类可以扩展父类的功能，但不要修改父类原有的功能。 也就是说，当一个子类继承父类后，尽量不要去重写它原有的方法。

依赖转置（依赖倒置）原则

要面向接口编程，不要面向实现编程。两个模块交互时，都访问各自接口，而不是具体的实现类。

单一职责原则

一个对象要专注于一种事情，不要让它担任太多责任。

接口隔离原则

一个接口尽量只包含用户关心的内容。就是一个接口不要太庞大。

迪米特法则

如果两个软件实体之间不是特别必要，尽量不要让他们直接通信。而是找个第三方进行转发，比如使用MQ（消息队列）。

合成复用原则

如果在“组合/聚合”和“继承”之间做抉择时，优先选择“组合/聚合”。

设计模式的分类

设计模式分为：

• 创建型模式：用于创建对象的设计模式。一般可以简化用户创建对象的过程。其次可以降低耦合度，用户不需要关心对象具体的创建过程。
  • 包含：单例模式、原型模型、工厂模式、建造者模式
• 结构型模型：组织对象之间的结构。使其易于扩展等。
  • 包括：代理模式、适配器模式、桥接模式、装饰器模式、外观模式、享元模式、组合模式
• 行为模型：主要用于决定对象如何做出行为
  • 包括：模板方法模式、策略模式、命令模式、责任链、状态模式、观察者模式、中介者模式、迭代器模式、访问者模式、备忘录模式、解释器模式

创建型模式

单例模式

• 模式名称：单例，顾名思义，就是单个实例。整个应用程序只需要一个实例即可。
• 问题：有很多情况下，只需要一个实例即可。现实生活中，地球、中国等，如果创建这些实例，那么只需要一个即可。 在代码世界中，全局上下文、线程池、连接池这些对象，在整个程序中也是只需要一个实例即可。
• 解决方案：禁止用户new该对象。只能通过你提供的静态方法来获取该对象。而你的静态方法返回的都是同一实例。
• 效果：避免用户new多个没用的对象。提高了系统性能

单例模式提供了两种方式：

• 懒汉模式：重点是懒。系统运行初期并不把该单例对象实例化，而是等第一次使用的时候再进行实例化。就像你平时懒得学习，非要等到考前才学一样。

public static synchronized LazySingleton getInstance() {
    //getInstance 方法前加同步
    if (instance == null) {
        instance = new LazySingleton();
    }
    return instance;
}
1
2
3
4
5
6
7

• 饿汉模式：重点是饿，也就是饥渴。还没到用的时候，就先实例化了，等到用的时候直接就可以用了。就像平时对知识很饥渴，学好了，然后直接面试就行了。

private static final HungrySingleton instance = new HungrySingleton();
public static HungrySingleton getInstance() {
    return instance;
}
1
2
3
4

原型模型

• 模式名称：原型（prototype）就是人们常说的，把XXX作为原型，然后弄一个跟它差不多的。
• 问题：经常会遇到需要克隆一个对象，然后对其稍作修改的业务场景。此时就可以使用原型模型，将对象A作为原型，然后克隆出一个对象B。
• 解决方案：重写对象的clone方法。也可以根据需求自己写。根据实际需要决定要深拷贝还是浅拷贝。
• 效果：简化了创建对象的过程

补充，深拷贝的实现方式：

• 方法1：可以将其转成json，然后再转换回来
• 方法2：若不方便转为json，可以将其序列化，然后再反序列化。

工厂模式

简单工厂模式

• 模式名称：和生活中的工厂一样，通过工厂来生产产品（对象），而不是自己手动new。
• 问题：生活中，你不可能所有产品都自己生产，所以你会把需求给工厂说，然后工厂给你生产，比如我想要黄色的衣服，工厂就给我生产一个黄色的衣服。 在程序中也一样，我通过工厂类，提出我的需求（传递参数），然后工厂类帮我new相应的对象，返回给我。
• 解决方案：定义一个抽象对象（如动物），然后定义一个工厂类，工厂类封装了生产具体动物（当然这些具体动物要继承动物类）的方法。然后你通过参数传递给工厂类，比如要一只汪汪叫的动物，然后工厂方法就会return new Dog()。
• 效果：用户不必关心对象怎么生产的，甚至不用关心这个具体对象是什么。工厂的生产规则可以写入配置文件，这样修改时就不需要动代码了。

工厂方法模式

在简单工厂中，有一个缺点：如果我们想让工厂再能多生产一种东西，那就要修改这个工厂类的方法。这显然不符合开闭原则。

针对这个问题，所以引出了工厂方法模式。

在简单工厂模式中，不管生产什么品牌的鞋子，都用同一工厂。

而在工厂方法模式中，想要生产某一个品牌的鞋子，就使用其对应的工厂。也就是说一个工厂只生产一种产品，如果你想要的三种不同的产品，你就要有三个工厂。比如，耐克工厂专门生产耐克鞋，阿迪工厂专门生产阿迪鞋。当你后期想要扩展的时候，你就可以再来一个安踏工厂专门生产安踏鞋。

抽象工厂模式

在工厂方法模式中，存在一个缺点，一个工厂只能生产一种产品。如耐克工厂只能生产耐克鞋。但是如果我想让耐克工厂即能生产耐克鞋也可以生产耐克衣服就没办法了。

所以为了解决这个问题，就引出了抽象工厂。在抽象工厂类中定义多个产品，即定义它的子类应该生产哪些产品。 这样就可以做到，耐克厂可以生产耐克鞋和耐克衣服，阿迪工厂可以生产阿迪鞋和阿迪衣服。

但是很明显有一个缺点：如果抽象工厂再加一种产品，比如帽子，那么所有的具体工厂类都要改造。

简单工厂、工厂方法和抽象工厂三者有什么区别

• 简单工厂：所有的产品都由一个工厂生产。如果你想加产品，就改源代码。
• 工厂方法：有多个工厂，但一个工厂只生产一种产品。如耐克厂只生产耐克鞋，阿迪厂只生产阿迪鞋。如果你想加产品，那就加工厂类。
• 抽象工厂：有多个工厂，每个工厂可以生产多类产品。如耐克厂可以生产耐克鞋和耐克衣服，阿迪厂可以生产阿迪鞋和阿迪衣服。但如果你想生产帽子，那么就需要在抽象工厂里加抽象方法，然后修改所有的子类。

建造者模式（Builder）

• 模式名称：用户就是建造者，自己动手造自己想要的东西。
• 问题：有些产品需要由多个部件组成，比如电脑需要键盘、鼠标、显示器、音响、主机等等。这些东西有些需要，有些也可以不需要，有些可以随便用（取默认值）。将其抽象到代码世界，若这些配置的组合方式全部弄成构造函数，那需要好多构造函数。用户光看这些构造函数就看晕了。
• 解决方案：可以将每个部件的构造过程都封装成方法，提供给用户，用户选完自己的部件后，调用build()方法构建出他想要的对象。

Computer computer=new Computer.Builder("因特尔","三星")
                .setDisplay("三星24寸")
                .setKeyboard("罗技")
                .setUsbCount(2)
                .build();
1
2
3
4
5

• 效果：用户可以定制化自己的产品。避免臃肿的构造方法。

结构型模式

代理模式

• 模型名称：和生活中的代理一个意思。本来该我做的事情，我找个代理人替我做。
• 问题：我想把房子租出去，但是又不想直接带人看房，原因有很多：找客户、风险等。所以我找个中介（代理），让他替我把房子租出去。在代码世界中，前端调用一个后台方法，因为风险（要验证其是否登录），我不想让它直接调用核心方法，而是让它调用代理对象，如果没有风险，再由这个代理对象替它调用核心方法。
• 解决方案：新建代理类，在代理类的方法中调用实际方法，可以在实际方法前后增加逻辑。当访问该方法时，不new该方法对应的对象，而是new其代理对象。通常有动态代理和静态代理
• 效果：可以在方法前后增加一些业务逻辑，如日志、安全校验等。

代理模式的实现方式：

• 静态代理：程序员自己编写代理类。或者是通过特定工具生成代理类（如AspectJ）。总之，在上JVM运行前的class文件中，代码用的就已经是代理类了。
• 动态代理：在程序运行时，通过反射机制动态创建。如Spring AOP就是用的动态代理类。

Spring AOP如何进行动态代理

@Autowired
private IService service;
1
2

你在写代码时，你并没有实例化这个service。而是将该实例通过spring进行注入，这样spring在就可以在运行时，根据你配置的规则，来决定这个service应该使用正常的bean还是使用其代理类。

装饰器模式

• 模式名称：和现实装饰一样，在外层再套一层皮。
• 问题：若我现在全裸，我想给自己装饰一下，那么我就可以在外层套一个外套。要是想再装饰，可以在外面再套一个貂皮大衣。在代码世界中，我可以在一个核心方法外再套一层计时功能，然后可以再套一层日志功能。 总之就是在方法的前后增加一些逻辑。
• 解决方案：最简单的方式是继承该类，然后重写其方法，在前后增加逻辑，但是这样不符合里氏替换原则。可以通过定义装饰器类，该装饰器类和具体要装饰的类都来自同一父类，由该装饰器类负责装饰，用户调用时调用该装饰器类。
• 效果：可以装饰原有类，可以提供更强劲的功能。

装饰器的典型应用：

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

装饰器模式为FileReader增加了Buffer功能。

装饰器模式和代理模式的区别

共同点：

• 效果类似：装饰器模式和代理模式都可以在方法的前后增加逻辑
• 可以嵌套：代理可以层层代理，装饰也可以层层装饰

区别：

• 实现方式不同：代理类和原有类之间并没有什么直接关联。就像我找中介帮我卖房子，我和中介之间并没有什么直接关系，我出钱他办事，我是我，他是他。但是装饰类和被装饰类之间就有关系，他们有共同的父类。比如BufferReader装饰了FileReader，他们有共同的父类Reader。
• 应用场景不同：代理模式主要用来做AOP，适用于同时对好多方法做切面。就像中介也不可能只帮我一个人卖房子。 而装饰器只专注于装饰一个类，BufferReader只专注于装饰Reader。

适配器模式

• 模式名称：在现实世界中，充电器全名为电源适配器。它的作用是将220V的交流电转化为5V的直流电。适配器就是一个转换器，将两种不兼容的东西，通过转换器使其互相兼容。
• 问题：在现实世界有很多适配器。在代码世界中，同样有很多相互之间不兼容的接口或类，它们之间无法直接相互调用，所以就需要适配器来进行转换。如"手机"调用"电源适配器"的充电接口，然后由电源适配器调用电源来获取电。
• 解决方案：适配器（充电器）通过组合（也可以使用继承，但不推荐）的形式保存适配者（手机）的引用。同时适配器实现目标对象（电源）的方法（充电）。当用户要给访问目标方法时，就new一个适配器，然后将适配者传给适配器，通过适配器访问目标方法。 比如，用户要给手机充电时，先new一个充电器，然后把手机连上充电器（把手机对象传给充电器），然后充电器访问电源的充电方法。
• 效果：解决了两个对象之间不兼容导致无法调用的问题。

主要角色解释：

• 适配器：就是充电器。负责数据转换
• 适配者：就是手机。
• 目标对象：就是电源。

桥接模式

• 模式名称：桥接个人理解是一个桥将两端接起来。我也不知道这么模式为什么这么起名，可能是因为该模式的英文名是Bridge吧。
• 问题：通常一个角色可能不止有一种属性。比如皮包，可以有颜色、品牌、类型等不同维度的属性。如果使用子类的形式来构建不同的对象，如黄色LV钱包，这样的话子类的数量就会非常庞大。子类总数 = 颜色 × 品牌 × 类型。
• 解决方案：选定一个属性作为主属性，使用继承的方式实现主属性。然后剩下的属性通过组合的方式实现。
• 效果：优化了因属性太多导致有过多子类的问题。

在该图中，选定Bag的类型作为主属性，通过继承的方式定义不同的Bag。而包的颜色作为次要属性，通过组合的方式进行实现。

外观模式（Facade）

• 模式名称： 外观模式也叫门面模式。门面模式可能更形象一点。将所有细节都封装起来，只给你提供一个门面，你通过这个门面来做自己要做的事。
• 问题：当你去银行办理业务时，流程可能很复杂，比如要先到窗口A登记信息，到窗口B验证信息，再到窗口C办理业务，最后到窗口D拿结果。
• 解决方案：新建一个门面类（Facade），使用组合的方式组合窗口ABCD，然后只为客户提供一个窗口，客户在这个窗口就可以办理完毕。
• 效果：降低了子系统和客户之间的耦合度。

扩展：
这个模式有一个缺点，如果要增加子系统，或者变更外观角色，那么就要修改源代码，不符合开闭原则。 解决方案也很简单，只需要对外观角色提供抽象即可。

将外观对象提供一个抽象类。客户在使用时，使用其抽象类，这样在变更子系统后，可以重新创建一个具体外观类。

享元模式

• 模式名称：享元就是分享元数据。其中元为本原，也可以理解为本质。比如围棋子对象，可以有坐标、颜色、大小等。但围棋子的本质是它的颜色和大小，坐标是它的次要属性（每个棋子的坐标基本都不一样）
• 问题：在程序中，需要创建大量相似的对象。比如围棋，需要很多围棋对象，它们除了坐标不一样，其他属性基本一致。LOL中的小兵，除了位置血量等不一样，其他属性也基本一样。假如每生成一个小兵，都使用深拷贝，那么内存中就会存在大量重复的数据。这样我的小破电脑肯定吃不消。
• 基本概念： 这里插一条概念解释。
  • 外部状态：会改变的属性称为外部属性，如五子棋的坐标。它对应的对象被称为非享元对象。
  • 内部状态：不会改变的属性。如五子棋的大小等。它对应的对象被称为享元对象。
• 解决方案：将原本的整个对象抽象出享元对象和非享元对象，然后通过工厂进行管理。用户通过工厂获取对象，工厂组合享元对象和非享元对象返回给用户。
• 效果：优化了内存占用

扩展：

• 单纯享元对象： 如果没有非享元对象，那么就称为单纯享元对象。此时就像是一个工厂管理着许多单例对象。
• 复合享元对象：有非享元对象，就是上面那张图的情况。

享元模式和原型模式比较

共同点：它们都适用于，如果两个元素改动比较小的话，可以使用该模式。

区别：

• 享元模式：适用于存在大量相似元素，且相似元素可以抽象出共同点（内部状态）。代码相对复杂。
• 原型模式：如果一共就不几个相似元素，直接用原型模式即可，没必要写享元模式。

组合模式

• 模式名称：把一堆对象组合起来，组成一个大的新的对象。
• 问题：如果你想让一个人拥有游泳、绘画、编程三个技能，你可以实现这三个接口，如果他们是类，你可以不断继承 人->编程->绘画->游泳，但是这样显然不合适。
• 解决方案：使用“组合/聚合”的形式，让“人”对象组合这三个技能即可。可以在人对象中定义一个 List<Ability>。
• 效果：后期对组合对象加元素时比较方便，易扩展。

其实这种模式大家应该基本天天在用，就是对象里面套对象。只不过可能不知道这也是一种设计模式而已。

行为型模型

观察者模式

• 模式名称：作为偷窥者，看到脱衣服，要流鼻血，看到自己被发现了，要跑。作为观察者同样，当被观察的事物状态发生变化时，观察者要做出相应的反映。
• 问题：在代码世界，用户也想让自己的对象监听（观察）另一个对象，当另一个对象发生变化后，能够回调自己的对象的方法，但是他们不知道怎么做。
• 解决方案：目标（被观察者）对象要包含观察者列表，当目标对象状态发生变化时，目标对象要依次调用观察者的通知方法。
• 效果：目标对象发生变化时，会通知观察者。

用通俗的语言解释一下观察者模式：

1. 小明、小王、小李三人想在考研政策变化的时候立刻做出反应。所以他们想作为观察者来观察考研政策的变化。因此，他们要继承观察者（Observer）接口，并实现反应（response）方法。
2. 小明等三人只实现了接口，还没有在研招网上进行注册，那研招网肯定没办法通知他们。但同样此时，研招网也没有开通注册通道，他们也没法注册。
3. 所以，研招网继承了抽象目标类，该类包含了注册、注销、通知用户等抽象方法。研招网继承该类并实现其抽象方法。
4. 研招网开通了注册通道后，小明三人就在研招网上进行注册。此时研招网就已经知道要通知哪些人了。
5. 之后，研招网有了新动态（目标对象状态发生了变化），变化的同时，研招网也会调用自己的notifyObserver()方法，该方法就是依次通知所有的观察者，相当于回到了小明三人的response方法。
6. 小明三人收到了通知，得知了最新的考研政策。小明、小红开始努力学习，小李选择放弃考研。

中介者模式（mediator）

• 模式名称：mediator为“调停者；传递者；中介物”，意思为“充当各方之间联系纽带的谈判者”。
• 问题：现实中充满了各种网状结构。如朋友圈是一个网，每个人是这张网上的一个节点。所有的租客和房主也能形成一张网等等。如果是网状结构，会存在一个问题，一个人的电话号码修改了，他需要提前通知所有的朋友。房主的房租降价了，也需要通知所有找房的租客。但如果把网状结构改为星状结构，有一个星星作为所有人中间的桥梁，那么问题就影刃而解了。于是QQ出现了 、房产中介出现了。 在代码世界中，也存在，当一方状态改变，他需要发送消息通知其他人（也可以是单纯的发送消息），那么应该怎么做呢？
• 解决方案：定义一个中介类，提供注册和转发的功能。“其他同事”可以把自己注册到中介系统中。并同时拿着中介的联系方式（引用）。其他同事需要提供接收和发送的接口。这样，用户就可以调用其中一个同事的发送接口，然后发送接口调用中介的转发接口，让其通知其他同事。
  • 同事：中介服务的对象称为同事。
• 效果：将网状结构转为星状结构，降低了各个同事之间的耦合性。

• register：负责注册同事。如果你不来婚姻介绍所注册登记，人家怎么给你介绍对象
• relay：转发消息。将消息转发给其他同事

    public void relay(Colleague cl) {
        for (Colleague ob : colleagues) {
            if (!ob.equals(cl)) {
                ((Colleague) ob).receive();
            }
        }
    }
1
2
3
4
5
6
7

• receive：接收消息。中介的转发消息会调用每个同事的该方法。
• send：发送消息。用户可以调用同事的该方法来发送消息，该方法会调用中介的relay方法来让中介去通知其他同事。这也就是为什么同事类要包含中介的引用。

    public void send() {
        System.out.println("具体同事类1发出请求。");
        mediator.relay(this); //请中介者转发
    }
1
2
3
4

中介者模式和观察者模式对比

相同点：中介者模式和观察者模式都可以用于当一方状态发生变化时通知其他人。

区别：

• 观察者模式：主要用于一对多。多个对象观察一个对象。观察者和目标对象通常不一致。比如，多个人观察天气变化。
• 中介者模式：主要用于多对多，大家都是观察者，同时也都是目标对象。每个对象也都一样，至少是同一种抽象。比如群聊，每个人都可以发消息，然后通过中介转发给其他所有人。

模板方法模式

• 模式名称：与现实中的模板一致。拿一个简历模板，把里面内容改改。拷贝别人的代码模板，把里面内容改改。
• 问题：在代码世界，经常会遇到很多逻辑相似的地方，但还不太一样。比如用纯jdbc操作数据库时，要连接数据库、构建Statement、写sql、获取结果、把结果转为对象。虽然都是这个流程，但是每次还都不太一样。如果每次都是复制之前的代码，然后改改，那会出现大量重复的代码。如果后期出现需求变换，比如要改下Statement的实现类，那所有涉及到的地方都要改。
• 解决方案：将相同的过程抽象成一个抽象类，一模一样的地方用具体方法，不一样的地方使用抽象方法。下次再使用时，只需要继承该抽象类，然后实现其抽象方法即可。
• 效果：减少了大量的重复逻辑。

策略模式

• 模式名称：一个人想干一件事，有很多策略，然后他选其中一种策略来做。
• 问题：用户想对一组数据进行排序，有很多策略可以选，如冒泡排序、快速排序、堆排序等。他不太确定后期会不会变，要是为每种排序都写一个类，而后期想切换排序就会很麻烦。
• 解决方案：定义一个接口，让其他排序类继承这个接口。用户在使用时不使用具体的类，而是使用接口。这样后期变更策略时，不会影响用户的代码。
• 效果：将行为和具体实现分离开，便于后期扩展和维护。

策略模式其实到处都是，一个接口有好几个实现类，你选择其中一个进行使用。

但有一点不同的是，策略模式需要有策略的选择角色，比如环境类。通过设置环境对象，让环境对象帮助用户选择使用哪一种策略，而不是由用户自己选择。

策略模式也可以和工厂模式结合使用，使用工厂来决定应该生产出哪一种策略来让用户使用。

命令模式

• 模式名称：在Linux中，用户使用工具基本都靠命令。一般都是封装一个cli，如redis-cli，用户通过客户端发送命令给服务端，然后服务端做响应的处理。同样这个思想可以放到面向对象编程中。
• 问题：如果两个模块相互之间调用时，使用直接调用的方法，这样耦合性太高了。这样的话，其中一方升级，增加了命令，另一方想要使用，就必须跟着升级。
• 解决方案：在请求者和接受者之间加一层命令类，通过命令对象来决定请求者发出的这个请求，应该由哪个接受者进行处理。
• 效果：对请求者和接受者进行了解构。一方的改动不会影响到另一方。

责任链模式

• 模式名称：一个人想办理一个业务，这个时候需要找有关部门，因为有关部门有责任帮用户办理该业务。 那为什么称为责任链呢？因为这个业务比较复杂，可能会分为以下两种情况：
  • 纯的责任链（推卸责任）：A部门说，这个不归我管，你去找B部门问问。结果B部门又让用户找C部门，C让用户找D，最终形成一条责任链，A->B->C->D。但是这条链上一定会有一个部门可以处理。
  • 不纯的责任链（都有责任）：A部门，我签好字了，你去找B部门继续签字，B部门签完后，继续找C部门签字。最后形成一条责任链A->B->C。这条责任链中，每一个对象都担负了一定责任。
• 问题：不管是现实世界，还是代码世界，都会存在这种的责任链现象。一个对象的处理需要不断的向后传递。
• 解决方案：定义一个抽象处理者，其中包含了下一环节的处理者，和一些抽象方法（如设置下一环节处理者，处理对象等）。根据需求定义具体处理者（继承抽象继承者）。用户在使用时，声明各个具体处理者的实例，然后将其穿成一个链，然后将对象交给链中的第一个处理者进行处理。
• 效果：
  • 增加了系统的可扩展性（如果对象增加处理，只需要增加处理对象并将其加入责任链中）。
  • 在纯的责任链中，避免了很多if-else语句。如果不用责任链的话，那就是使用if-else或switch语句来判断应该选用处理类进行处理。

状态模式

• 模式名称：人有不同的状态，人在不同的状态下，同样的事情会有不同的反映。对于对象来说，也会有不同的状态，也应该具备对不同状态做出不同反映的能力。
• 问题：如果我有一个电梯对象，它具有停止、正在上升、正在下降等状态。此时如果用户按下了某个楼层，电梯应该如何根据自己当前状态做出反应呢？
• 解决方案：定义状态抽象类，其中包括抽象方法Handle。让具体状态类实现抽象状态类，实现其Handle方法。有状态对象使用组合的方式集成状态对象，并提供设置状态接口。 比如：①定义电梯状态抽象类。②定义“上升状态”、“下降状态”和“停止状态”三个类，并实现抽象类中的“用户按下按键”方法。③电梯对象中使用组合的方式集成“状态”对象。
• 效果：符合单一职责原则，一个类只干一件事。将状态与实际对象分离，实现解耦。

迭代器模式

• 模式名称：迭代就是遍历一个集合
• 问题：如果我想遍历一个集合，可以使用for循环。但是有一个缺点，我需要知道集合的大小，并且该集合还要能支持随机访问 ，比如list[3]这样。但是Set就不支持这种随机访问（随机访问可以理解为通过下标进行访问）。那能不能提供一种统一的遍历方式，且不需要关心它是否支持随机访问呢？
• 解决方案：定义一个Iterator接口，包含next()，hasNext()方法。让你需要遍历的对象实现该接口，通过下面这种方式访问

while(obj.hasNext()) {
	obj.next();
}
1
2
3

• 效果：遍历对象无需知道它的内部结构，比如如何获取它的长度等。

扩展：
平时用的 for-each 的本质就是迭代器模式。例如下列代码：

public class Test implements Iterable {

    public Iterator iterator() {
        return null;
    }

    public static void main(String[] args) {
        Test test = new Test();
        for (Object o : test) {
            System.out.println(o);
        }
    }
}
1
2
3
4
5
6
7
8
9
10
11
12
13

该代码是可以编译通过的，因为Test类实现了Iterable方法，所以可以使用for-each遍历它。否则，则编译会报错。

访问者模式

访问者模式 （偷个懒）

备忘录模式（快照模式）

• 模式名称：个人感觉快照模式这个名字更合适。为对象打一个快照，当发现对象出问题时，可以恢复到之前的快照版本。
• 问题：在使用虚拟机时，我们经常给虚拟机打快照，如果后面出问题了，可以恢复。在面向对象编程中，也会出现类似的需求。比如你要对一个对象进行一系列的操作，如果失败的话，就会滚到之前的状态，所以你需要在开始之前为对象打一个快照。
• 解决方案：新建一个管理者，负责管理快照。当你要备份快照前，你可以使用原型模式来生成一份一样的对象，交给管理者来管理。当需要恢复时，通过管理者来恢复到之前的快照。
• 效果：可以方便的管理备份和恢复对象

解释器模式

• 模式名称：Javascript、Python这些都是解释性语言。而将字符翻译成机器语言的东西就称为“解释器”
• 问题：若你也想定义一种解释性语言怎么办？
• 解决方案：定义解释器。这个就不深入讲了（其实我不会，而且面试官基本也都不会）
• 效果：比如Hibernate定义有HQL，还有SpringEL。这些都算是利用解释器模式来方便的让用户更灵活的达到自己想要的效果。