什么是设计模式

设计模式（Design pattern）是一套被反复使用、多数人知晓的、经过分类的、代码设计经验的总结。

使用设计模式的目的

使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
设计模式是软件工程的基石脉络，如同大厦的结构一样。

设计模式和设计原则的关系

设计原则是设计模式的参考标准，设计模式尽可能的遵循、满足设计原则

类与接口

在谈设计模式之前，我们先来谈谈类与接口，因为所有的设计模式都是在类与接口的基础之上搞出来的。

什么是类和接口

• 类是同种对象的集合与抽象
• 接口是对行为的抽象

类的成员有哪些

1、字段
2、函数
函数分为构造函数和业务函数
3、其他（内部类、代码块等等）

类、接口之间的关系

image

共6种，我来简单的谈谈我对这些关系的理解，更详细的大家可以百度

关联

被关联一方是关联一方的成员变量，即has-a的关系

继承

is-a的关系

实现

对接口的实现

依赖

依赖一方的函数的形参包含被依赖的一方

聚合、组合

这个两个比较容易搞混
聚合(Aggregation) 关系是关联关系的一种，是强的关联关系。聚合是整体和个体之间的关系（参考雁群和大雁的关系）
组合(Composition) 关系是关联关系的一种，是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分对象的生命周期，组合关系是不能共享的。（参考大雁和大雁翅膀的关系）

小结

我们在上面简单叙述了什么是设计模式，设计模式的作用，什么是类与接口，类、接口之间的关系，类的成员。我们的设计模式是基于类与接口以及它们之间的关系的，以设计原则为参考标准。如果我们把类和接口玩熟了，那么只要理清它们的关系，整个设计模式的学习过程就快了。

设计模式的分类

一般是将设计模式分为三类

• 创建型
  主要对类对象创建进行处理
• 结构型
  主要处理类、接口之间的关系
• 行为性
  主要处理业务函数

下面我们分别对这三类设计模式进行学习分析

创建型设计模式

1. Factory Method（工厂方法）

定义一个用于创建对象的接口，让子类决定实例化哪一个类。
Factory Method 使一个类的实例化延迟到其子类。

适用性：

• 当一个类不知道它所必须创建的对象的类的时候。
• 当一个类希望由它的子类来指定它所创建的对象的时候。

• 当类将创建对象的职责委托给多个帮助子类中的某一个，并且你希望将哪一个帮助子类是代理者这一信息局部化的时候。

  
  
  0_12939589723Ggs.gif

个人理解：

工厂方法模式比较简单，主要是将对象的创建和初始化进行了封装，对外封装了整个对象的初始化过程。让我们在实例化对象的过程当中有了很大的操作空间。尤其是在各种开源框架中被广泛使用。不过这些开源框架更多的是简单工厂结合反射和xml文件解析（或注解）的使用。

2. Abstract Factory（抽象工厂）

提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。

适用性：

• 一个系统要独立于它的产品的创建、组合和表示时。
• 一个系统要由多个产品系列中的一个来配置时。
• 当你要强调一系列相关的产品对象的设计以便进行联合使用时。

• 当你提供一个产品类库，而只想显示它们的接口而不是实现时。

  
  
  0_1293958972yHTZ.gif

个人理解：

抽象工厂和工厂方法功能蛮像的，不过工厂方法针对的是某类抽象产品去创建。而抽象工厂则是诊针对某系列抽象产品去创建。更多内容可以参看这篇

建造者

将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

适用性：

• 当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

• 当构造过程必须允许被构造的对象有不同的表示时。

  
  
  0_1293958973l0eX.gif

个人理解：

其实建造者模式还是蛮难理解的，看上面的类图也是挺容易懵逼的。我们把握好几个比较重要的点就行了。

• 复杂对象
  如果对象不复杂那就没必要了，直接new出来就行了。
• 相同的装配过程
  我们把这个复杂对象的装配过程流程化，然后每次实例化的时候走这个固定流程就行了。
• 创建不同的表示
  这个需要对创建流程中的会变化的步骤进行抽象，让这些抽象的创建步骤根据具体的子类有不同的创建能力。从而达到创建结果相同的创建过程，不同的表示形式。

Prototype（原型）

用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

适用性：

• 当要实例化的类是在运行时刻指定时，例如，通过动态装载；
• 或者为了避免创建一个与产品类层次平行的工厂类层次时；

• 或者当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。

  
  
  0_1293958973KlLw.gif

个人理解

原型模式不难理解，简单来说是我们java开发中克隆，但就是不知该什么时候用，上述的几个场景在Spring框架中可以见到它们的踪影。
对于克隆，有两点我们可以去深入的了解一下。克隆的实现方式，以及深浅克隆。在这里不做详述。

5. Singleton（单例）

保证一个类仅有一个实例，并提供一个访问它的全局访问点。

适用性：

• 当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。

• 当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

  
  
  0_1293958973z20x.gif

个人理解

单例模式估计大家都比较熟悉了，我们需要注意的是关于懒汉和饿汉两种情况，以及懒汉模式下线程安全的处理。
　　在项目中单例模式中可以说是大家最常使用的，但是我却不推荐大家使用单例模式，单例模式简单来说有以下问题：

• 扩展困难，由于GetInstance静态函数没有办法生成子类的实例。如果要拓展，只有重写那个类。
• 单例类的职责过重，在一定程度上违背了“单一职责原则”。
• 导致程序内存泄露的问题，new出来对象的生命周期过长。

总结：

到现在五大创建型的设计模式已经说完了，可能到这里大家还是比较懵。这个不要紧。设计模式的学习需要在项目的开发中和阅读代码时融会贯通的。毕竟设计模式是经验总结出来的东西。所以对于学习者的经验要求比较高。不懂也没关系，背一背、记一记。读写代码的时候在想一想就能理解了。