小知识，大挑战！本文正在参与“   程序员必备小知识   ”创作活动

本文同时参与 「掘力星计划」   ，赢取创作大礼包，挑战创作激励金

六个创建型模式

1.简单工厂模式

2.工厂方法模式

3.抽象工厂模式

4.单例模式

单例模式：

单例模式(Singleton Pattern)：确保某一个类只有一个实 例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方 法。单例模式是一种对象创建型模式。

单例模式有三个要点：

一是某个类只能有一个实例；二是它必须自行创建这个实例；三是它 必须自行向整个系统提供这个实例。

饿汉式单例模式：

饿汉式单例类在类被加载时就将自己实例化，它的优点在于无须考虑多线程访问问题，可以 确保实例的唯一性；从调用速度和反应时间角度来讲，由于单例对象一开始就得以创建，因 此要优于懒汉式单例。但是无论系统在运行时是否需要使用该单例对象，由于在类加载时该 对象就需要创建，因此从资源利用效率角度来讲，饿汉式单例不及懒汉式单例，而且在系统 加载时由于需要创建饿汉式单例对象，加载时间可能会比较长。

懒汉式单例模式：

懒汉式单例类在第一次使用时创建，无须一直占用系统资源，实现了延迟加载，但是必须处 理好多个线程同时访问的问题，特别是当单例类作为资源控制器，在实例化时必然涉及资源 初始化，而资源初始化很有可能耗费大量时间，这意味着出现多线程同时首次引用此类的机 率变得较大，需要通过双重检查锁定等机制进行控制，这将导致系统性能受到一定影响。

IoDH:

IoDH，我们既可以实现延迟加载，又可以保证线程安全，不影响系统性能，不失为 一种最好的Java语言单例模式实现方式（其缺点是与编程语言本身的特性相关，很多面向对象 语言不支持IoDH）。

单例模式总结：

1.主要优点

单例模式的主要优点如下： (1) 单例模式提供了对唯一实例的受控访问。因为单例类封装了它的唯一实例，所以它可以严 格控制客户怎样以及何时访问它。 (2) 由于在系统内存中只存在一个对象，因此可以节约系统资源，对于一些需要频繁创建和销 毁的对象单例模式无疑可以提高系统的性能。 (3) 允许可变数目的实例。基于单例模式我们可以进行扩展，使用与单例控制相似的方法来获 得指定个数的对象实例，既节省系统资源，又解决了单例单例对象共享过多有损性能的问 题。

2.主要缺点

单例模式的主要缺点如下： (1) 由于单例模式中没有抽象层，因此单例类的扩展有很大的困难。 (2) 单例类的职责过重，在一定程度上违背了“单一职责原则”。因为单例类既充当了工厂角 色，提供了工厂方法，同时又充当了产品角色，包含一些业务方法，将产品的创建和产品的 本身的功能融合到一起。 (3) 现在很多面向对象语言(如Java、C#)的运行环境都提供了自动垃圾回收的技术，因此，如 果实例化的共享对象长时间不被利用，系统会认为它是垃圾，会自动销毁并回收资源，下次 利用时又将重新实例化，这将导致共享的单例对象状态的丢失。

3.适用场景 在以下情况下可以考虑使用单例模式：

(1) 系统只需要一个实例对象，如系统要求提供一个唯一的序列号生成器或资源管理器，或者 需要考虑资源消耗太大而只允许创建一个对象。 (2) 客户调用类的单个实例只允许使用一个公共访问点，除了该公共访问点，不能通过其他途 径访问该实例。

5.原型模式

原型模式(Prototype Pattern)：

使用原型实例指定创建对象的种类，并且通过拷贝这些 原型创建新的对象。需要注意的是通过克隆方法所创建的对象是全新的对象，它们在内存中拥有新的地址，通常 对克隆所产生的对象进行修改对原型对象不会造成任何影响，每一个克隆对象都是相互独立 的。通过不同的方式修改可以得到一系列相似但不完全相同的对象

深克隆，浅克隆

1.浅克隆

在浅克隆中，如果原型对象的成员变量是值类型，将复制一份给克隆对象；如果原型对象的 成员变量是引用类型，则将引用对象的地址复制一份给克隆对象，也就是说原型对象和克隆 对象的成员变量指向相同的内存地址。简单来说，在浅克隆中，当对象被复制时只复制它本 身和其中包含的值类型的成员变量，而引用类型的成员对象并没有复制

2.深克隆

无论原型对象的成员变量是值类型还是引用类型，都将复制一份给克隆对象， 深克隆将原型对象的所有引用对象也复制一份给克隆对象。简单来说，在深克隆中，除了对 象本身被复制外，对象所包含的所有成员变量也将复制。

在Java语言中，如果需要实现深克隆，可以通过序列化(Serialization)等方式来实现。序列化就 是将对象写到流的过程，写到流中的对象是原有对象的一个拷贝，而原对象仍然存在于内存 中。通过序列化实现的拷贝不仅可以复制对象本身，而且可以复制其引用的成员对象，因此 通过序列化将对象写到一个流中，再从流里将其读出来，可以实现深克隆。需要注意的是能 够实现序列化的对象其类必须实现Serializable接口，否则无法实现序列化操作

原型管理器的引入和实现

原型管理器(Prototype Manager)是将多个原型对象存储在一个集合中供客户端使用，它是一个 专门负责克隆对象的工厂，其中定义了一个集合用于存储原型对象，如果需要某个原型对象 的一个克隆，可以通过复制集合中对应的原型对象来获得。在原型管理器中针对抽象原型类 进行编程，以便扩展。

原型模式总结

1.主要优点

原型模式的主要优点如下： (1) 当创建新的对象实例较为复杂时，使用原型模式可以简化对象的创建过程，通过复制一个 已有实例可以提高新实例的创建效率。 (2) 扩展性较好，由于在原型模式中提供了抽象原型类，在客户端可以针对抽象原型类进行编 程，而将具体原型类写在配置文件中，增加或减少产品类对原有系统都没有任何影响。 (3) 原型模式提供了简化的创建结构，工厂方法模式常常需要有一个与产品类等级结构相同的 工厂等级结构，而原型模式就不需要这样，原型模式中产品的复制是通过封装在原型类中的 克隆方法实现的，无须专门的工厂类来创建产品。 (4) 可以使用深克隆的方式保存对象的状态，使用原型模式将对象复制一份并将其状态保存起 来，以便在需要的时候使用（如恢复到某一历史状态），可辅助实现撤销操作。

2.主要缺点 原型模式的主要缺点如下：

(1) 需要为每一个类配备一个克隆方法，而且该克隆方法位于一个类的内部，当对已有的类进 行改造时，需要修改源代码，违背了“开闭原则”。 (2) 在实现深克隆时需要编写较为复杂的代码，而且当对象之间存在多重的嵌套引用时，为了 实现深克隆，每一层对象对应的类都必须支持深克隆，实现起来可能会比较麻烦。

3.适用场景

在以下情况下可以考虑使用原型模式： (1) 创建新对象成本较大（如初始化需要占用较长的时间，占用太多的CPU资源或网络资 源），新的对象可以通过原型模式对已有对象进行复制来获得，如果是相似对象，则可以对 其成员变量稍作修改。 (2) 如果系统要保存对象的状态，而对象的状态变化很小，或者对象本身占用内存较少时，可 以使用原型模式配合备忘录模式来实现。 (3) 需要避免使用分层次的工厂类来创建分层次的对象，并且类的实例对象只有一个或很少的 几个组合状态，通过复制原型对象得到新实例可能比使用构造函数创建一个新实例更加方 便

6.建造者模式

建造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可 以创建不同的表示。建造者模式是一种对象创建型模式。

建造者模式总结

1.主要优点

建造者模式的主要优点如下： (1) 在建造者模式中，客户端不必知道产品内部组成的细节，将产品本身与产品的创建过程解 耦，使得相同的创建过程可以创建不同的产品对象。 (2) 每一个具体建造者都相对独立，而与其他的具体建造者无关，因此可以很方便地替换具体 建造者或增加新的具体建造者，用户使用不同的具体建造者即可得到不同的产品对象。由于 指挥者类针对抽象建造者编程，增加新的具体建造者无须修改原有类库的代码，系统扩展方 便，符合“开闭原则” (3) 可以更加精细地控制产品的创建过程。将复杂产品的创建步骤分解在不同的方法中，使得 创建过程更加清晰，也更方便使用程序来控制创建过程。

2.主要缺点

建造者模式的主要缺点如下： (1) 建造者模式所创建的产品一般具有较多的共同点，其组成部分相似，如果产品之间的差异 性很大，例如很多组成部分都不相同，不适合使用建造者模式，因此其使用范围受到一定的 限制。 (2) 如果产品的内部变化复杂，可能会导致需要定义很多具体建造者类来实现这种变化，导致 系统变得很庞大，增加系统的理解难度和运行成本。

3.适用场景

在以下情况下可以考虑使用建造者模式： (1) 需要生成的产品对象有复杂的内部结构，这些产品对象通常包含多个成员属性。 (2) 需要生成的产品对象的属性相互依赖，需要指定其生成顺序。 (3) 对象的创建过程独立于创建该对象的类。在建造者模式中通过引入了指挥者类，将创建过 程封装在指挥者类中，而不在建造者类和客户类中。 (4) 隔离复杂对象的创建和使用，并使得相同的创建过程可以创建不同的产品。

七个结构型模式

1.适配器模式

适配器模式(Adapter Pattern)：将一个接口转换成客户希望的另一个接口，使接口不兼容的那 些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可 以作为对象结构型模式。

对象适配器

在对象适配器模式结构图中包含如下几个角色： ● Target（目标抽象类）：目标抽象类定义客户所需接口，可以是一个抽象类或接口，也可以 是具体类。 ● Adapter（适配器类）：适配器可以调用另一个接口，作为一个转换器，对Adaptee和Target进 行适配，适配器类是适配器模式的核心，在对象适配器中，它通过继承Target并关联一个 Adaptee对象使二者产生联系。 ● Adaptee（适配者类）：适配者即被适配的角色，它定义了一个已经存在的接口，这个接口 需要适配，适配者类一般是一个具体类，包含了客户希望使用的业务方法，在某些情况下可 能没有适配者类的源代码。 根据对象适配器模式结构图，在对象适配器中，客户端需要调用request()方法，而适配者类 Adaptee没有该方法，但是它所提供的specificRequest()方法却是客户端所需要的。为了使客户 端能够使用适配者类，需要提供一个包装类Adapter，即适配器类。这个包装类包装了一个适 配者的实例，从而将客户端与适配者衔接起来，在适配器的request()方法中调用适配者的 specificRequest()方法。因为适配器类与适配者类是关联关系（也可称之为委派关系），所以 这种适配器模式称为对象适配器模式。典型的对象适配器代码如下所示：

class Adapter extends Target { 
private Adaptee adaptee; //维持一个对适配者对象的引用 
public Adapter(Adaptee adaptee) {
 this.adaptee=adaptee; 
 }
 public void request() {
  adaptee.specificRequest(); //转发调用
   } }

类适配器

除了对象适配器模式之外，适配器模式还有一种形式，那就是类适配器模式，类适配器模式 和对象适配器模式最大的区别在于适配器和适配者之间的关系不同，对象适配器模式中适配 器和适配者之间是关联关系，而类适配器模式中适配器和适配者是继承关系

双向适配器

在对象适配器的使用过程中，如果在适配器中同时包含对目标类和适配者类的引用，适配者 可以通过它调用目标类中的方法，目标类也可以通过它调用适配者类中的方法，那么该适配 器就是一个双向适配器

缺省适配器

缺省适配器模式是适配器模式的一种变体，其应用也较为广泛。缺省适配器模式的定义如 下：缺省适配器模式(Default Adapter Pattern)：当不需要实现一个接口所提供的所有方法时，可先 设计一个抽象类实现该接口，并为接口中每个方法提供一个默认实现（空方法），那么该抽 象类的子类可以选择性地覆盖父类的某些方法来实现需求，它适用于不想使用一个接口中的 所有方法的情况，又称为单接口适配器模式。

适配器模式总结

适配器模式将现有接口转化为客户类所期望的接口，实现了对现有类的复用，它是一种使用 频率非常高的设计模式，在软件开发中得以广泛应用，在Spring等开源框架、驱动程序设计 （如JDBC中的数据库驱动程序）中也使用了适配器模式。

1. 主要优点

无论是对象适配器模式还是类适配器模式都具有如下优点： (1) 将目标类和适配者类解耦，通过引入一个适配器类来重用现有的适配者类，无须修改原有 结构。 (2) 增加了类的透明性和复用性，将具体的业务实现过程封装在适配者类中，对于客户端类而 言是透明的，而且提高了适配者的复用性，同一个适配者类可以在多个不同的系统中复用。 (3) 灵活性和扩展性都非常好，通过使用配置文件，可以很方便地更换适配器，也可以在不修 改原有代码的基础上增加新的适配器类，完全符合“开闭原则”。

对象适配器模式还有如下优点：

(1) 一个对象适配器可以把多个不同的适配者适配到同一个目标； (2) 可以适配一个适配者的子类，由于适配器和适配者之间是关联关系，根据“里氏代换原 则”，适配者的子类也可通过该适配器进行适配。

1. 主要缺点

类适配器模式的缺点如下： (1) 对于Java、C#等不支持多重类继承的语言，一次最多只能适配一个适配者类，不能同时适 配多个适配者； (2) 适配者类不能为最终类，如在Java中不能为final类，C#中不能为sealed类； (3) 在Java、C#等语言中，类适配器模式中的目标抽象类只能为接口，不能为类，其使用有一 定的局限性。

对象适配器模式的缺点如下：

与类适配器模式相比，要在适配器中置换适配者类的某些方法比较麻烦。如果一定要置换掉 适配者类的一个或多个方法，可以先做一个适配者类的子类，将适配者类的方法置换掉，然 后再把适配者类的子类当做真正的适配者进行适配，实现过程较为复杂。

2.桥接模式

桥接模式是一种很实用的结构型设计模式，如果软件系统中某个类存在两个独立变化的维 度，通过该模式可以将这两个维度分离出来，使两者可以独立扩展，让系统更加符合“单一职 责原则”。与多层继承方案不同，它将两个独立变化的维度设计为两个独立的继承等级结构， 并且在抽象层建立一个抽象关联，该关联关系类似一条连接两个独立继承结构的桥，故名桥 接模式。

桥接模式总结

桥接模式是设计Java虚拟机和实现JDBC等驱动程序的核心模式之一，应用较为广泛。在软件 开发中如果一个类或一个系统有多个变化维度时，都可以尝试使用桥接模式对其进行设计。 桥接模式为多维度变化的系统提供了一套完整的解决方案，并且降低了系统的复杂度。

1.主 要优点

桥接模式的主要优点如下： (1)分离抽象接口及其实现部分。桥接模式使用“对象间的关联关系”解耦了抽象和实现之间固 有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽象和实现沿着各自维度 的变化，也就是说抽象和实现不再在同一个继承层次结构中，而是“子类化”它们，使它们各自 都具有自己的子类，以便任何组合子类，从而获得多维度组合对象。 (2)在很多情况下，桥接模式可以取代多层继承方案，多层继承方案违背了“单一职责原则”， 复用性较差，且类的个数非常多，桥接模式是比多层继承方案更好的解决方法，它极大减少 了子类的个数。 (3)桥接模式提高了系统的可扩展性，在两个变化维度中任意扩展一个维度，都不需要修改原 有系统，符合“开闭原则”。

2.主要缺点

桥接模式的主要缺点如下： (1)桥接模式的使用会增加系统的理解与设计难度，由于关联关系建立在抽象层，要求开发者 一开始就针对抽象层进行设计与编程。 (2)桥接模式要求正确识别出系统中两个独立变化的维度，因此其使用范围具有一定的局限 性，如何正确识别两个独立维度也需要一定的经验积累。

3、组合模式

组合模式(Composite Pattern)：组合多个对象形成树形结构以表示具有“整体—部分”关系的层 次结构。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致 性，组合模式又可以称为“整体—部分”(Part-Whole)模式，它是一种对象结构型模式。

• Component（抽象构件）：它可以是接口或抽象类，为叶子构件和容器构件对象声明接口， 在该角色中可以包含所有子类共有行为的声明和实现。在抽象构件中定义了访问及管理它的子构件的方法，如增加子构件、删除子构件、获取子构件等。
• Leaf（叶子构件）：它在组合结构中表示叶子节点对象，叶子节点没有子节点，它实现了在 抽象构件中定义的行为。对于那些访问及管理子构件的方法，可以通过异常等方式进行处 理
• Composite（容器构件）：它在组合结构中表示容器节点对象，容器节点包含子节点，其子 节点可以是叶子节点，也可以是容器节点，它提供一个集合用于存储子节点，实现了在抽象 构件中定义的行为，包括那些访问及管理子构件的方法，在其业务方法中可以递归调用其子 节点的业务方法。

组合模式总结：

组合模式使用面向对象的思想来实现树形结构的构建与处理，描述了如何将容器对象和叶子 对象进行递归组合，实现简单，灵活性好。由于在软件开发中存在大量的树形结构，因此组 合模式是一种使用频率较高的结构型设计模式，Java SE中的AWT和Swing包的设计就基于组 合模式，在这些界面包中为用户提供了大量的容器构件（如Container）和成员构件（如 Checkbox、Button和TextComponent等），

主要优点

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

主要缺点

组合模式的主要缺点如下： 在增加新构件时很难对容器中的构件类型进行限制。有时候我们希望一个容器中只能有某些 特定类型的对象，例如在某个文件夹中只能包含文本文件，使用组合模式时，不能依赖类型 系统来施加这些约束，因为它们都来自于相同的抽象层，在这种情况下，必须通过在运行时 进行类型检查来实现，这个实现过程较为复杂。

4.装饰模式

装饰模式是一种用于替代继承的技术，它通过一种无须定义子类的方式来给对象动态增加职 责，使用对象之间的关联关系取代类之间的继承关系。在装饰模式中引入了装饰类，在装饰 类中既可以调用待装饰的原有类的方法，还可以增加新的方法，以扩充原有类的功能。

装饰模式总结

装饰模式降低了系统的耦合度，可以动态增加或删除对象的职责，并使得需要装饰的具体构 件类和具体装饰类可以独立变化，以便增加新的具体构件类和具体装饰类。在软件开发中， 装饰模式应用较为广泛，例如在JavaIO中的输入流和输出流的设计、javax.swing包中一些图形 界面构件功能的增强等地方都运用了装饰模式。

1.主要优点

装饰模式的主要优点如下： (1) 对于扩展一个对象的功能，装饰模式比继承更加灵活性，不会导致类的个数急剧增加。 (2) 可以通过一种动态的方式来扩展一个对象的功能，通过配置文件可以在运行时选择不同的 具体装饰类，从而实现不同的行为。 (3) 可以对一个对象进行多次装饰，通过使用不同的具体装饰类以及这些装饰类的排列组合， 可以创造出很多不同行为的组合，得到功能更为强大的对象。 (4) 具体构件类与具体装饰类可以独立变化，用户可以根据需要增加新的具体构件类和具体装 饰类，原有类库代码无须改变，符合“开闭原则”。

2.主要缺点

装饰模式的主要缺点如下： (1) 使用装饰模式进行系统设计时将产生很多小对象，这些对象的区别在于它们之间相互连接 的方式有所不同，而不是它们的类或者属性值有所不同，大量小对象的产生势必会占用更多 的系统资源，在一定程序上影响程序的性能。 (2) 装饰模式提供了一种比继承更加灵活机动的解决方案，但同时也意味着比继承更加易于出 错，排错也很困难，对于多次装饰的对象，调试时寻找错误可能需要逐级排查，较为繁琐

5.外观模式

外观模式定义如下： 外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义 了一个高层接口，这个接口使得这一子系统更加容易使用。

总结：

模式优点

外观模式的主要优点如下： (1) 它对客户端屏蔽了子系统组件，减少了客户端所需处理的对象数目，并使得子系统使用起 来更加容易。通过引入外观模式，客户端代码将变得很简单，与之关联的对象也很少。 (2) 它实现了子系统与客户端之间的松耦合关系，这使得子系统的变化不会影响到调用它的客 户端，只需要调整外观类即可。 (3) 一个子系统的修改对其他子系统没有任何影响，而且子系统内部变化也不会影响到外观对 象。

2模式缺点

外观模式的主要缺点如下： (1) 不能很好地限制客户端直接使用子系统类，如果对客户端访问子系统类做太多的限制则减 少了可变性和灵活 性。 (2) 如果设计不当，增加新的子系统可能需要修改外观类的源代码，违背了开闭原则。