一、什么是设计模式

设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。这个术语是由埃里希·伽玛（Erich Gamma）等人在 1990 年代从建筑设计领域引入到计算机科学的。

二、为什么要用设计模式

  1. 可读性 (即：编程规范性,  便于其他程序员的阅读、理解和维护)；
  2. 代码重用性 (即：相同功能的代码，不用多次编写)；
  3. 可扩展性 (即：当需要增加新的功能时，非常的方便，称为可维护)
  4. 可靠性 (即：当我们增加新的功能后，对原来的功能没有影响)
  5. 使程序呈现高内聚，低耦合的特征；

三、设计模式遵循的原则

3.1开闭原则


开闭原则（Open Closed Principle）是编程中最基础、最重要的设计原则。


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

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

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

想要达到这样的效果，我们推荐面向接口编码，即需要使用接口或抽象类。

3.2单一职责原则

简单地说，一个类只负责一项职责。

问题：比如一个类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。

解决方法：遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

3.3接口隔离原则

使用多个隔离的接口，比使用单个接口要好。即客户端不应该依赖它不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上。

3.4依赖倒转原则

高层模块不应该依赖低层模块，二者都应该依赖其抽象。

抽象不应该依赖细节，细节应该依赖抽象。

依赖倒转(倒置)的中心思想是面向接口编程。

依赖倒转原则是基于这样的设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在 java 中，抽象指的是接口或抽象类，细节就是具体的实现类

使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成

3.5迪米特法则

迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的 public 方法，不对外泄露任何信息。迪米特法则还有个更简单的定义：只与直接的朋友通信。

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

3.6里氏替换原则

继承包含这样一层含义：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低， 增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障。

在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法。里氏替换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖 来解决问题。例如：子类B必须要重写父类A的方法operation1()，则可以将A类中除了operation1()之外的所有方法抽取到一个基类BaseService中，然后A和B都继承BaseService，并单独定义operatin1()方法；如果B类需要用到A类的方法，则在B类中注入A类即可；

四、常见设计模式


设计模式分为三种类型，共 23 种

  • 创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式。
  • 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式。
  • 行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式（Interpreter 模式）、状态模式、策略模式、职责链模式(责任链模式)。


注意：不同的书籍上对分类和名称略有差别

4.1创建型模式的特点和分类

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

创建型模式分为以下几种。

  • 单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其拓展是有限多例模式。
  • 原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。
  • 工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。
  • 抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。
  • 建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

以上 5 种创建型模式，除了工厂方法模式属于类创建型模式，其他的全部属于对象创建型模式，我们将在之后的教程中详细地介绍它们的特点、结构与应用。

 

五、设计模式常见面试题

5.1原型设计模式问题

  1. 有请使用 UML 类图画出原型模式核心角色。
  2. 原型设计模式的深拷贝和浅拷贝是什么，并写出深拷贝的两种方式的源码(重写 clone 方法实现深拷贝、使用序列化来实现深拷贝)。
  3. 在 Spring 框架中哪里使用到原型模式，并对源码进行分析。

5.2解释器设计模式


  1. 介绍解释器设计模式是什么?
  2. 画出解释器设计模式的 UML 类图,分析设计模式中的各个角色是什么?
  3. 请说明 Spring 的框架中，哪里使用到了解释器设计模式，并做源码级别的分析
  4. Spring 框架中 SpelExpressionParser 就使用到解释器模式
  5. 代码分析+Debug 源码+模式角色分析说明