工作好些年了，设计模式这么好玩的东西一直没有好好整理整理，这次抽空好好给它抽筋扒皮梳理清楚它。在正式开干之前，得先搞清楚一些问题：设计模式是什么？我们为啥要用设计模式？
一、设计模式是什么
设计模式（design pattern）是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案
设计模式是一套理论，由软件界的先辈们（四人帮：The Gang of Four）：包括Erich Gamma、Richard Helm、Ralph Johnson、John Vlissides 总结的一套可以反复使用的经验，它可以提高代码的可重用性，增强系统的可维护性，以及解决一系列的复杂问题。做软件的人都知道需求是最难把握的，我们可以分析现有的需求，预测可能发生的变更，但是我们不能控制需求的变更。问题来了，既然需求的变更是不可控的，那如何拥抱变化呢？幸运的是，设计模式给了我们指导，专家们首先提出了6大设计原则，但这6大设计原则仅仅是一系列“口号”，真正付诸实施还需要有详尽的指导方法，于是23种设计模式出现了。
据说设计模式起源于建筑学，想想也是，软件工程只有短短的几十年，与已经拥有几千年底蕴的建筑工程相比，后者有太多值得学习和借鉴的地方。
二、设计模式能干什么
换句话说，我们为什么要学习设计模式？
其实类似大家这样有一定工作经验的开发人员，了解以及进一步掌握设计模式是非常有必要的，因为平时大家接到开发任务，首要目标是实现功能，而且现在的节奏~，时间紧，任务重，大家没有，可能也来不及做其他的考虑，所以，大部分程序员写的代码，其实可维护性，可读性都很差，类之间的关系非常复杂，没有条理，那例如以后要增加新的需求，现有的程序如何进行变动成本最低？如何保证新的功能模块不会对原来的项目产生影响？
设计模式是为了让软件（程序）具有更好的代码重用性，可读性，可扩展性，可靠性
理论听着云里雾里，那到底是什么意思呢？
1. 代码重用性：即相同功能的代码，不需要多次编写，可以重复使用
2. 可读性：即编码的规范性，便于其他程序员阅读和理解
3. 可扩展性：即当需要增加新功能时，成本低，也称为可维护性
4. 可靠性：即代码强壮，当增加新的功能时，对原有的功能没有影响
其实说到底，就是让程序呈现出高内聚，低耦合的特性
耦合主要描述模块之间的关系，内聚主要描述模块内部，当然模块的粒度可大可小（小到一个类 大-到一个系统）
1. 高内聚： 高内聚就是提高接口、类、模块的处理能力，独立性强，一个模块应当尽可能独立完成某个功能，减少对外的交互。比如你告诉下属“到奥巴马的办公室偷一个×××文件”，然后听到下属用坚定的口吻回答你：“是，保证完成任务！”一个月后，你的下属还真的把×××文件放到你的办公桌上了，这种不讲任何条件、立刻完成任务的行为就是高内聚的表现。具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。
2. 低耦合： 功能模块和功能模块之间耦合性很低，A模块出现问题，避免影响B模块，比如模块A直接操作了模块B中数据, 则视为强耦合，例如下图，我们假设这样一个场景，发货系统发货，写入消息队列，订单系统这边订阅消息队列里的消息，如果订单系统出现故障，不影响发货系统正常写入消息队列，利用了消息中间件，两个系统之间的耦合性大大降低
三、设计模式遵循的原则
换句话说，设计模式遵循的原则就是：设计模式为什么这么设计的依据，它们是各种设计模式的基础，也是我们程序员在编程的时候应当遵守的原则。
《设计模式之禅（第二版）》中，作者认为有六种设计原则：单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则。其实，不少地方还提到了合成复用原则，其实是七种设计原则：
总原则：开闭原则（Open Close Principle）
开闭原则就是说对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。想要达到这样的效果，我们需要使用接口和抽象类等。
1、单一职责原则 不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，如若不然，就应该把类拆分。
2、里氏替换原则（Liskov Substitution Principle） 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。 LSP是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。—— From Baidu 百科
里氏替换原则中，子类对父类的方法尽量不要重写和重载。因为父类代表了定义好的结构，通过这个规范的接口与外界交互，子类不应该随便破坏它。
3、依赖倒转原则（Dependence Inversion Principle） 这个是开闭原则的基础，具体内容：面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。
4、接口隔离原则（Interface Segregation Principle） 这个原则的意思是：每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的接口，比使用单个接口（多个接口方法集合到一个的接口）要好。
5、迪米特法则（最少知道原则）（Demeter Principle） 就是说：一个类对自己依赖的类知道的越少越好。也就是说无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。
最少知道原则的另一个表达方式是：只与直接的朋友通信。类之间只要有耦合关系，就叫朋友关系。耦合分为依赖、关联、聚合、组合等。我们称出现为成员变量、方法参数、方法返回值中的类为直接朋友。局部变量、临时变量则不是直接的朋友。我们要求陌生的类不要作为局部变量出现在类中。
6、合成复用原则（Composite Reuse Principle） 原则是尽量首先使用合成/聚合的方式，而不是使用继承。
博主寂然对其重要性做了总结（主观的）
| 名称 | 设计原则简介 | 重要性 |
|---|---|---|
| 单一职责原则 | 类的职责要单一，不能将太多的职责放在一个类中 | ★★★★☆ |
| 开闭原则 | 软件实体对扩展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去扩展其功能 | ★★★★★ |
| 里氏代换原则 | 在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象 | ★★★★☆ |
| 依赖倒置原则 | 要针对抽象层编程，而不要针对具体类编程 | ★★★★★ |
| 接口隔离原则 | 使用多个专门的接口来取代一个统一的接口 | ★★☆☆☆ |
| 合成复用原则 | 在系统中应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系 | ★★★★☆ |
| 迪米特法则 | 一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用，而是通过引入一个第三者发生间接交互 | ★★★☆☆ |
四、设计模式分类
关于这个，不同的人，不同的书都有不同的看法，比较经典的《设计模式：可复用面向对象软件的基础》一书中，认为可以将23中设计模式分为三类：创建型、结构型、行为型，在《大话设计模式（吴强）》一书中，则是分成了接口型、责任型、构造型、操作型、扩展型五类。
通常来看，大多数人还是遵循比较经典的《设计模式：可复用面向对象软件的基础》沿袭的说法，将23中设计模式分成了创建型、结构型、行为型这三类。
1、创建型模式，共五种：工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。
2、结构型模式，共七种：适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。
3、行为型模式，共十一种：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
这样，整体上，就对设计模式有了一个认知。
参考文档：
https://baijiahao.baidu.com/s?id=1712015814495812140&wfr=spider&for=pc
https://developer.aliyun.com/article/780970?spm=a2c6h.13262185.profile.34.1d934622rlwa7W#slide-7
https://blog.csdn.net/u012869196/article/details/73616182
注意：本文归作者所有，未经作者允许，不得转载