三言两语总结GoF23种设计模式_gof的思想

设计模式

背景

学习编程开发，设计模式几乎是必学的，但是设计模式比较多，非常容易弄混，也不容易理解。所以将设计模式的精要总结下来，方便理解。

什么是设计模式？

设计模式是一套面向对象的代码设计经验总结，是一套用来提高代码可复用性、可维护性、可读性、稳健性以及安全性的解决方案。是一种思想，而非具体的技术。

1995 年，GoF（Gang of Four，四人组/四人帮）合作出版了《设计模式：可复用面向对象软件的基础》一书，共收录了 23 种设计模式，从此树立了软件设计模式领域的里程碑，人称「GoF设计模式」。

为什么使用设计模式？

设计模式的本质是面向对象设计原则的实际运用，是对类的封装性、继承性和多态性以及类的关联关系和组合关系的充分理解。正确使用设计模式具有以下优点：

• 可以提高程序员的思维能力、编程能力和设计能力。
• 使程序设计更加标准化、代码编制更加工程化，使软件开发效率大大提高，从而缩短软件的开发周期。
• 使设计的代码可重用性高、可读性强、可靠性高、灵活性好、可维护性强。

七大设计原则

设计原则核心思想

1. 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一起。
2. 针对接口编程，而不是针对实现编程。
3. 为了交互对象之间的松耦合设计而努力

以下为简单总结七大设计原则的概念和特点，如果想要详细了解七大设计原则，请参考我的博客：

设计模式(一)——七大原则详解

单一职责原则

一个类应该有且仅有一个引起它变化的原因，否则类应该被拆分。

违背单一职责缺点

1. 一个职责变化，可能影响这个类对其他职责的实现。
2. 一个类职业庞大，维护更加麻烦，可复用性随之降低，容易造成冗余代码或代码的浪费。（当客户端需要该对象的某一个职责时，不得不将其他不需要的职责全都包含进来）

作用

单一职责原则的核心就是控制类的粒度大小、将对象解耦、提高其内聚性。如果遵循单一职责原则将有以下优点。

• 降低类的复杂度。一个类只负责一项职责，其逻辑肯定要比负责多项职责简单得多。
• 提高类的可读性。复杂性降低，自然其可读性会提高。
• 提高系统的可维护性。可读性提高，那自然更容易维护了。
• 变更引起的风险降低。变更是必然的，如果单一职责原则遵守得好，当修改一个功能时，可以显著降低对其他功能的影响。

单一职责原则违反情况

1. 需要足够简单的逻辑，才可在代码级别违反单一职责原则
2. 需要类中方法数量足够少，才可以在方法级别上违反单一职责原则

接口隔离原则

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

理解：要为各个类建立它们需要的专用接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。

作用

接口隔离原则是为了约束接口、降低类对接口的依赖性，遵循接口隔离原则有以下 优点：

1. 提高系统的灵活性和可维护性（分解庞大接口，预防外来变更扩散）。
2. 提高系统内聚性，降低耦合性（减少对外交互）。
3. 提高系统稳定性（如果接口定义过小，则会造成接口数量过多，使设计复杂化；如果定义太大，灵活性降低，无法提供定制服务，给整体项目带来无法预料的风险）。
4. 使用多个专门的接口还能够体现对象的层次（因为可以通过接口的继承，实现对总接口的定义）。
5. 减少项目工程中的代码冗余（过大的大接口里面通常放置许多不用的方法，当实现这个接口的时候，被迫设计冗余的代码）。

接口隔离原则VS单一职责原则

接口隔离原则和单一职责都是为了提高类的内聚性、降低它们之间的耦合性，体现了封装的思想，但两者是不同的：

• 单一职责原则注重的是职责，而接口隔离原则注重的是对接口依赖的隔离。
• 单一职责原则主要是约束类，它针对的是程序中的实现和细节；接口隔离原则主要约束接口，主要针对抽象和程序整体框架的构建。

依赖倒转原则

高层模块不应该依赖低层模块，两者都应该依赖其抽象；抽象不应该依赖细节，细节应该依赖抽象。

核心思想：要面向接口编程，不要面向实现编程。

依赖倒置原则是实现开闭原则的重要途径之一，它降低了客户与实现模块之间的耦合。

作用

• 降低类间的耦合性。
• 提高系统的稳定性。
• 减少并行开发引起的风险。
• 提高代码的可读性和可维护性。

里氏替换原则

继承必须确保超类所拥有的性质在子类中仍然成立。

理解：

1. 子类型必须能够替换掉他们的父类型，并且不影响程序的功能（行为），是对实现抽象化的具体步骤的规范。
2. 子类可以扩展父类的功能，但不能改变父类原有的功能。也就是说：子类继承父类时，除添加新的方法完成新增功能外，尽量不要重写父类的方法。

作用

1. 里氏替换原则是实现开闭原则的重要方式之一。
2. 它克服了继承中重写父类造成的可复用性变差的缺点。
3. 它是动作正确性的保证。即类的扩展不会给已有的系统引入新的错误，降低了代码出错的可能性。

开闭原则

软件实体应当对扩展开放，对修改关闭。

这里的软件实体包括以下几个部分：

1. 项目中划分出的模块
2. 类与接口
3. 方法

含义：

当应用的需求改变时，在不修改软件实体的源代码或者二进制代码的前提下，可以扩展模块的功能，使其满足新的需求。

作用

开闭原则是面向对象程序设计的终极目标，它使软件实体拥有一定的适应性和灵活性的同时具备稳定性和延续性。具体来说，其作用如下。

1. 对软件测试的影响

软件遵守开闭原则的话，软件测试时只需要对扩展的代码进行测试就可以了，因为原有的测试代码仍然能够正常运行。

2. 可以提高代码的可复用性

粒度越小，被复用的可能性就越大；在面向对象的程序设计中，根据原子和抽象编程可以提高代码的可复用性。

3. 可以提高软件的可维护性

遵守开闭原则的软件，其稳定性高和延续性强，从而易于扩展和维护。

迪米特法则(最少知道原则)

如果两个软件实体无须直接通信，那么就不应当发生直接的相互调用，可以通过第三方转发该调用。

目的：降低类之间的耦合度，提高模块的相对独立性。

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

作用

迪米特法则要求限制软件实体之间通信的宽度和深度，正确使用迪米特法则将有以下两个优点。

1. 降低了类之间的耦合度，提高了模块的相对独立性。
2. 由于亲合度降低，从而提高了类的可复用率和系统的扩展性。

但是，过度使用迪米特法则会使系统产生大量的中介类，从而增加系统的复杂性，使模块之间的通信效率降低。所以，在釆用迪米特法则时需要反复权衡，确保高内聚和低耦合的同时，保证系统的结构清晰。

合成复用原则

尽量先使用组合或者聚合等关联关系来实现，其次才考虑使用继承关系来实现。

**如果要使用继承关系，则必须严格遵循里氏替换原则。**合成复用原则同里氏替换原则相辅相成的，两者都是开闭原则的具体实现规范。

继承复用的缺点

通常类的复用分为继承复用和合成复用两种，继承复用虽然有简单和易实现的优点，但它也存在以下缺点。

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

合成复用的优点

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

1. 它维持了类的封装性（因为成分对象的内部细节是新对象看不见的，所以这种复用又称为“黑箱”复用）。
2. 新旧类之间的耦合度低（这种复用所需的依赖较少，新对象存取成分对象的唯一方法是通过成分对象的接口）。
3. 复用的灵活性高（这种复用可以在运行时动态进行，新对象可以动态地引用与成分对象类型相同的对象）。

类之间的关系

在软件系统中，类不是孤立存在的，类与类之间存在各种关系。根据类与类之间的耦合度从弱到强排列，UML 中的类图有以下几种关系：依赖关系、关联关系、聚合关系、组合关系、泛化关系和实现关系。其中泛化和实现的耦合度相等，它们是最强的。

以下为简单总结类之间的关系，如果想要详细了解，请参考我的博客：

设计模式(二)——UML类图

1.依赖关系

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

只要是在类中用到了对方，那么他们之间就存在依赖关系。

2.关联关系

关联（Association）关系是对象之间的一种引用关系，用于表示一类对象与另一类对象之间的联系，如老师和学生、师傅和徒弟、丈夫和妻子等。

1. 关联关系实际上就是类与类之间的联系，它是依赖关系的特例
2. 关联关系具有导航型：即双向关系或单向关系
3. 关联关系具有多重性，即可以表示一对一、一对多、多对多的关系

3.聚合关系

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

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

4.组合关系

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

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

5.泛化关系

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

6.实现关系

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

创建型模式

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

单例模式(Singleton Pattern)

某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例。

单例模式有 3 个特点：

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

优点

1. 在系统设置全局的访问点，优化环共享资源访问

2. 只生成一个实例，减少了系统性能开销

单例模式详情参考我的博客：设计模式(三)——详解单例模式(Singleton Pattern)的8种写法

工厂模式(Factory Pattern)

实现了创建者和调用者的分离。将实例化对象的代码提取出来，放到一个类中统一管理和维护，达到和主项目的依赖关系的解耦。从而提高项目的扩展和维护性。

工厂模式详情参考我的博客：设计模式(四)——工厂模式(Factory Pattern)

简单工厂模式

1. 简单工厂模式也叫静态工厂模式，就是工厂类一般是使用静态方法，通过接收的参数的不同来返回不同的对象实例。
2. 在软件开发中，当我们会用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式
3. 对于增加新产品无能为力！不修改代码的话，是无法扩展的。

如果要创建的产品不多，只要一个工厂类就可以完成，这种模式叫“简单工厂模式”，它不属于 GoF 的 23 种经典设计模式，它的缺点是增加新产品时会违背“开闭原则”。

工厂方法（FactoryMethod）模式

定义一个创建产品对象的工厂接口，将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

1. 工厂方法模式和简单工厂模式最大的不同在于，简单工厂模式只有一个（对于一个项目或者一个独立模块而言）工厂类，而工厂方法模式有一组实现了相同接口的工厂类。
2. 避免简单工厂模式的缺点，不完全满足OCP。
3. 定义了一个创建对象的抽象方法，由子类决定要实例化的类。工厂方法模式将对象的实例化推迟到子类。

工厂方法模式的主要优点有：

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

其缺点是：增加了系统的复杂度（每增加一个产品就要增加一个具体产品类和一个对应的具体工厂类）。

抽象工厂（AbstractFactory）模式

提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。

使用抽象工厂模式一般要满足以下条件。

• 系统中有多个产品族，每个具体工厂创建同一族但属于不同等级结构的产品。
• 系统一次只可能消费其中某一族产品，即同族的产品一起使用。

抽象工厂模式除了具有工厂方法模式的优点外，其他主要优点如下。

• 可以在类的内部对产品族中相关联的多等级产品共同管理，而不必专门引入多个新的类来进行管理。
• 当增加一个新的产品族时不需要修改原代码，满足开闭原则。

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

原型模式(Prototype Pattern)

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

优点

允许一个对象再创建另外一个可定制的对象，无需知道如何创建的细节。

原型模式详情参考我的博客：设计模式(五)——原型模式(Prototype Pattern)

建造者模式(Builder Pattern)

将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象（构建和装配的解耦）。

本质

1. 分离了对象子组件的单独构造(由Builder来负责)和装配(由Director负责)。 从而可以构造出复杂的对象。这个模式适用于：某个对象的构建过程复杂的情况下使用。

2. 由于实现了构建和装配的解耦。不同的构建器，相同的装配，也可以做出不同的对象；相同的构建器，不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦，实现了更好的复用。

建造者模式详情参考我的博客：设计模式(六)——建造者模式(Builder Pattern)

结构型模式

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

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

适配器模式(Adapter Pattern)

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

分类

1. 类适配器模式
2. 对象适配器模式
3. 接口适配器模式

优点

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

缺点

过多的使用适配器，会让系统非常零乱，不易整体进行把握。

适配器模式详情参考我的博客：设计模式(七)——适配器模式(Adapter Pattern)

桥接模式(Bridge Pattern)

将抽象与实现放在两个不同的类层次中，使两个层次可以独立改变。

主要特点

1. 把抽象(Abstraction)与行为实现(Implementation)分离开来，从而可以保持各部分的独立性以及应对他们的功能扩展。
2. 它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。

核心要点

处理多层继承结构，处理多维度变化的场景，将各个维度设计成独立的继承结构，使各个维度可以独立的扩展在抽象层建立关联。

桥接模式详情参考我的博客：设计模式(八)——桥接模式(Bridge Pattern)

装饰者模式(Decorator Pattern)

动态地给对象增加一些职责，即增加其额外的功能。

装饰模式是一种用于代替继承的技术 ,无须通过继承增加子类就能扩展对象的新功能。使用对象的关联关系代替继承关系,更加灵活，同时避免类型体系的快速膨胀。

装饰（Decorator）模式的主要优点有：

• 采用装饰模式扩展对象的功能比采用继承方式更加灵活。
• 可以设计出多个不同的具体装饰类，创造出多个不同行为的组合。

其主要缺点是：装饰模式增加了许多子类，如果过度使用会使程序变得很复杂。

装饰者模式详情参考我的博客：设计模式(九)——装饰者模式(Decorator Pattern)

组合模式(Composite Pattern)

又叫部分整体模式，将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性，可以使用统一的方式处理部分对象和整体对象。

组合模式的主要优点有：

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

其主要缺点是：

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

组合模式详情参考我的博客：设计模式(十)——组合模式(Composite Pattern)

外观模式(Facade Pattern)

为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。

该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

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

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

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

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

外观模式详情参考我的博客：设计模式(十一)——外观模式(Facade Pattern)

享元模式(Flyweight Pattern)

运用共享技术来有效地支持大量细粒度对象的复用。

关键

享元对象能做到共享的关键是区分了内部状态和外部状态。

• 内部状态：存储在享元对象内部，可以共享，不会随环境变化而改变。
• 外部状态：对象得以依赖的一个标记，不可以共享，会随环境变化而改变。

它通过共享已经存在的又橡来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。

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

其主要缺点是：

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

外观模式详情参考我的博客：设计模式(十二)——享元模式(Flyweight Pattern)

代理模式(Proxy Pattern)

为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。

代理模式的主要优点有：

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

其主要缺点是：

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

代理模式详情参考我的博客：设计模式(十三)——代理模式(Proxy Pattern)

行为型模式

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

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

模板方法模式(Template Method Pattern)

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

该模式的主要优点如下。

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

该模式的主要缺点如下。

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

模板方法模式详情参考我的博客：设计模式(十四)——模板方法模式(Template Method Pattern)

命令模式(Command Pattern)

将一个请求封装为一个对象，使得请求发送者与请求接收者实现解耦。

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

1. 降低系统的耦合度。命令模式能将调用操作的对象与实现该操作的对象解耦。
2. 增加或删除命令非常方便。采用命令模式增加与删除命令不会影响其他类，它满足“开闭原则”，对扩展比较灵活。
3. 可以实现宏命令。命令模式可以与组合模式结合，将多个命令装配成一个组合命令，即宏命令。
4. 方便实现 Undo 和 Redo 操作。命令模式可以与后面介绍的备忘录模式结合，实现命令的撤销与恢复。

其缺点是：可能产生大量具体命令类。因为计对每一个具体操作都需要设计一个具体命令类，这将增加系统的复杂性。

命令模式详情参考我的博客：设计模式(十五)——命令模式(Command Pattern)

访问者模式(Visitor Pattern)

将作用于某种数据结构中的各元素的操作分离出来封装成独立的类，使其在不改变数据结构的前提下可以添加作用于这些元素的新的操作，为数据结构中的每个元素提供多种访问方式。

它将对数据的操作与数据结构进行分离，是行为类模式中最复杂的一种模式。

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

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

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

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

访问者模式详情参考我的博客：设计模式(十六)——访问者模式(Visitor Pattern)

迭代器模式(Iterator Pattern)

提供一种遍历集合元素的统一接口，用一致的方法遍历集合元素，不需要知道集合对象的底层表示，即：不暴露其内部的结构。

什么时候使用？

如果我们的集合元素是用不同的方式实现的，有数组，还有 java 的集合类，或者还有其他方式，当客户端要遍历这些集合元素的时候就要使用多种遍历方式，而且还会暴露元素的内部结构，可以考虑使用迭代器模式解决。

主要优点如下。

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

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

迭代器模式详情参考我的博客：设计模式(十七)——迭代器模式(Iterator Pattern)

观察者模式(Observer Pattern)

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

核心

观察者模式主要用于1 : N的通知。当一个对象(目标对象Subject或Objservable)的状态变化时（消息发布）；他需要及时告知一系列对象(观察者对象,Observer) ,令他们做出响应（消息订阅）。

通知观察者的方式:

消息订阅
●推

• 每次都会把通知以广播方式发送给所有观察者,所有观察者只能被动接收。

●拉

• 观察者只要直到有情况即可。至于什么时候获取内容,获取什么内容，都可以自主决定。

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

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

它的主要缺点如下。

1. 目标与观察者之间的依赖关系并没有完全解除，而且有可能出现循环引用。

2. 当观察者对象很多时，通知的发布会花费很多时间，影响程序的效率。

迭代器模式详情参考我的博客：设计模式(十八)——观察者模式(Observer Pattern)

中介者模式(Mediator Pattern)

定义一个中介对象来封装一系列的对象交互。中介者使各个对象不需要显式地相互引用，降低系统中对象间的耦合度，而且可以独立地改变它们之间的交互。

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

1. 降低了对象之间的耦合性，使得对象易于独立地被复用。
2. 将对象间的一对多关联转变为一对一的关联，提高系统的灵活性，使得系统易于维护和扩展。

其主要缺点是：当同事类太多时，中介者的职责将很大，它会变得复杂而庞大，以至于系统难以维护。

迭代器模式详情参考我的博客：设计模式(十九)——中介者模式(Mediator Pattern)

备忘录模式(Memento Pattern)

在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。

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

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

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

备忘录模式详情参考我的博客：设计模式(二十)——备忘录模式(Memento Pattern)

解释器模式(Interpreter Pattern)

提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

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

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

解释器模式详情参考我的博客：设计模式(二十一)——解释器模式(Interpreter Pattern)

状态模式(State Pattern)

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

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

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

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

1. 状态模式的使用必然会增加系统的类与对象的个数。
2. 状态模式的结构与实现都较为复杂，如果使用不当会导致程序结构和代码的混乱。

状态模式详情参考我的博客：设计模式(二十二)——状态模式(State Pattern)

策略模式(Strategy Pattern)

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

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

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

其主要缺点如下。

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

策略模式详情参考我的博客：设计模式(二十三)——策略模式(Strategy Pattern)

责任链模式(Chain of Responsibility Pattern)

把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

优点

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

缺点

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

责任链模式详情参考我的博客：设计模式(二十四)——责任链模式(Chain of Responsibility Pattern)