前言

《设计模式自习室》系列，顾名思义，本系列文章带你温习常见的设计模式。

但是，在开篇中，我想要先整体的介绍下设计模式，让大家知道为什么要学习设计模式。

所以这篇文章的主要内容是：

• 我对设计模式的理解
• 设计模式的至高目标：解耦（高内聚低耦合）
• 设计模式的分类
• 设计模式遵循的设计原则
• 为什么我写代码常常用不到设计模式？

文章会逐步更新于我的各个博客上（见文章尾部介绍），也希望各位观众老爷能够关注我的个人公众号：后端技术漫谈，所有文章都会在上面发布，不会错过精彩好看的文章。

为什么我们需要设计模式？

我对设计模式的理解

当我刚刚接触程序，最初听到“设计模式”这四个字的时候，我常常会思考一个问题，这个东西为什么这么拗口。就像我当初听到“离散数学”，“具体数学”一样，有种摸不着头脑的感觉。

带着这种疑问，我尝试看了几篇介绍设计模式的文章，它们都对设计模式进行了这样的介绍：

软件设计模式（Design pattern），又称设计模式，是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。 使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。

看完之后，我更加摸不着头脑了。看着什么单例模式，责任链模式的代码，感觉老师从来就没提过这些，为什么要把代码写成这样，好好的写完自己想要的功能不就好了嘛？？？

是的，设计模式，对于入门程序员来说，确实有点空中楼阁，尤其是对于没接触过大型项目的人而言，这些代码是如此的陌生，甚至有点“故弄玄虚”。

但是，生活往往就是有这么多“但是”！当你逐渐入门了程序编写，接触到了大型的，功能复杂的，需要多人合作的代码后，再回头看设计模式，往往就有了越来越清晰的认识。

随着我的经验积累，再回来复习设计模式，常常有醒悟的感觉。接下来就说说我对设计模式的认知：

设计模式的英文是什么？Design pattern，这是一个非常之准确的词汇，个人认为比中文翻译好太多了。

Patten中文释义：. n. 模式；图案；样品. vt. 模仿

pattern往往意味着是一种既定的准则，从它的动词可以看到，他有模仿的意思，也就是说，这样的代码设计，是一系列前人留下的经验，只要跟着这样写代码，往往能够让你的代码，更加简洁，更加健壮，更加优雅！

我觉得他应该有个意译的名字，叫做：代码设计的最佳实践！

是不是很耳熟，还记得最近很火的《阿里巴巴JAVA开发手册》，以及经典的《Effective Java》吗？他们都是属于经验总结型的知识，目的是帮助程序员写出更优雅的代码！

如果你没听过上面的几本书，没关系，当然，你也可以看看我之前的文章 《阿里巴巴Java开发手册》阅读笔记，大概了解下他们的内容是什么样的，你就会理解我说的“他们是一个类型的”。

高内聚低耦合

设计模式是一种代码设计思路，其最最本质的目的是为了解耦，延伸一点的话，还有为了可扩展性和健壮性，但是这都是建立在解耦的基础之上。

有同学要问了，“解耦”是什么意思呢？请先看下面两个概念：

高内聚

系统中A、B两个模块进行交互，如果修改了A模块，不影响模块B的工作，那么认为A是高度内聚的。

低耦合

那么当B发生改变时，A模块仍然可以正常工作，那么就认为A与B是低耦合的。

所以解耦，本质上就是让不同的代码块各司其职，互不干扰！

设计模式的分类

创建型模式

创建型模式将创建对象的过程进行了抽象，也可以理解为将创建对象的过程进行了封装，作为客户程序仅仅需要去使用对象，而不再关系创建对象过程中的逻辑。

• 简单工厂模式（Simple Factory）:简单工厂模式不是GoF总结出来的23种设计模式之一
• 工厂方法模式（Factory Method）
• 抽象工厂模式（Abstract Factory）
• 创建者模式（Builder）
• 原型模式（Prototype）
• 单例模式（Singleton）

结构型模式

结构型模式是为解决怎样组装现有的类，设计它们的交互方式。例如：扩展性（外观、组成、代理、装饰）、封装（适配器、桥接）。因为如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。

• 外观模式/门面模式（Facade门面模式）
• 适配器模式（Adapter）
• 代理模式（Proxy）
• 装饰模式（Decorator）
• 桥梁模式/桥接模式（Bridge）
• 组合模式（Composite）
• 享元模式（Flyweight）

行为型模式

行为模式刻划了在程序运行时难以跟踪的复杂的控制流，进一步可分为行为类模式和行为对象模式。

行为类模式使用继承机制在类间分派行为。

行为对象模式使用对象聚合来分配行为。一些行为对象模式描述了一组对等的对象怎样相互协作以完成其中任何一个对象都无法单独完成的任务。

• 模板方法模式（Template Method）
• 观察者模式（Observer）
• 状态模式（State）
• 策略模式（Strategy）
• 职责链模式（Chain of Responsibility）
• 命令模式（Command）
• 访问者模式（Visitor）
• 调停者模式（Mediator）
• 备忘录模式（Memento）
• 迭代器模式（Iterator）
• 解释器模式（Interpreter）

三者之间的区别和联系

创建型模式提供生存环境，结构型模式提供生存理由，行为型模式提供如何生存。

创建型模式为其他两种模式使用提供了环境。

结构型模式侧重于接口的使用，它做的一切工作都是对象或是类之间的交互，提供一个门。

行为型模式顾名思义，侧重于具体行为，所以概念中才会出现职责分配和算法通信等内容。

设计原则

设计模式是优雅的代码实现，所以会讲究标准的设计原则，常用的设计原则如下：

• 开闭原则： 对扩展开放，对修改关闭
• 里氏转换原则： 子类继承父类，单独完全可以运行
• 依赖倒转原则： 引用一个对象，如果这个对象有底层类型，直接引用底层类型
• 接口隔离原则： 每一个接口应该是一种角色
• 合成/聚合复用原则： 新的对象应使用一些已有的对象，使之成为新对象的一部分
• 迪米特原则： 一个对象应对其他对象有尽可能少的了解

为什么我写代码常常用不到设计模式？

这一点，是我临时加上的，因为我之前也有这样的困惑。看了这么多设计模式，为什么我日常使用中根本就不会想到去用呢？我想给出几点回答：

第一，我们日常开发中，经常是使用框架在构造大型的项目，框架已经为我们考虑到了太多的设计，已经让我们开箱即用。所以我们常常只需要CRUD（增删改查）。其实框架的源码中，使用到了非常多的设计模式，这也是为什么很多大牛在推荐我们看某某框架的源码前，常常建议我们先看设计模式。否则看源码的时候，会非常的吃力，因为不知道为什么会这样写代码

第二，设计模式的使用往往在你的编程经验积累到一定程度后，在遇到了大量的问题后，你会想着去进行合理的代码结构设计来解决一些常常会遇到的问题，这时候，你就会慢慢的想到使用设计模式了！所以不要急，你可以先不用强行往自己的项目上放设计模式，但一定要先了解各种设计模式

第三，如果你急着想要上手实践设计模式，那么，做一个完全不依赖大型框架的项目吧，可以是一个工具类，可以是一个小功能脚本，只要不依赖那些复杂的框架，很快你就能发现你代码中可以应用设计模式的地方，别问我怎么知道的，快去自己造一个轮子吧！