1、前言
前两年工作中多有用到一些设计模式，但是除了早年在大学里学过一遍设计模式之后，一些不常用的设计模式渐渐忘记了。我意识到这是一件很可怕的事情，因为能在需要时恰好被想起的知识才是自己的知识，而我在忙碌中某些知识却默默遗失了。温故而知新，所以最近重新温习了一遍，有了新的领悟： 知识与知识之间是有关联的，学习不是靠死记硬背的，理解 + 输出 = 自己的知识。
划重点： 高效的学习方式应该是巧妙串联所有的知识，这里设计模式也是！
2、基本原则
世界上所有的真理都是从问题开始的。所以，在说哪几个基本原则之前提出几个问题：
- 在面向对象设计中，如果我把很多复杂的功能都放在一个类(我们假定这个类名叫A)不行吗？ 为什么要按功能定义分开？
- 前面的类A设计好， 之后，但需求总是在变化的，如果每次修改都要修改它，
会很容易出bug，怎么办？ - 假设前面的类A 是由算法B类实现的，现在希望用算法C类 来实现，又要改动到类A了，好麻烦啊，怎么办？
- 现在我学会了抽象，于是我把用户的功能都提炼成接口，第二天有新增了别的功能，有一定相关性，那么我是新建立一个接口还是继续在原有接口上新增？
- 假设现在A类提供了打印的功能，但此时有需要传真的功能，我用类D实现它，最后把D类提供给客户，这样让客户同时知道类A 以及 D 有什么问题 ?
问题的解决：
一个类如果包括了超过一个功能，那么以后它就有多个被修改的理由了，功能越多，修改的机会就越大，它就会变成大杂烩，越来越复杂，越来越难以维护，修改一点点就会出个bug。
所以，前人提炼出第一个基本原则 ：单一职责；
每一个类都应该有则仅有一个功能，这样后面维护性就很强；当软件需要变化时，我们应该尽量通过扩展的方式来达到，而不是修改已有的代码来实现，这样可维护性强，问题也少。所以，这里引出第二个原则： 开闭原则 ；
-
对于第三个问题，回想到面向对象设计的3大特点就是： 继承、封装和多态。
所以，对于对于同一个算法行为，我们可以定义的抽象类，然后类B 以及 类 C 继承实现具体的算法思想，然后在A中只需要引用抽象父类即可，怎么换都不需要变化了。这里的思想包括了2个原则：- LSP : 里氏替换原则，所有引用基类的地方都可以用子类来代替；
- DIP : 依赖倒置原原则，细节应该依赖于抽象，而抽象不应该依赖细节，因为细节总是变化的，而抽象总是不变化的
第4个问题： 最好的方式是新建接口，因为新增的功能不一定是原有所有使用方都需要的，如果加上，势必对他们造成困扰。所以这里引出第五个原则：
ISP 接口隔离原则，即客户端不应该依赖于它本不需要的接口，这就要求我们接口的设计应该越简单，越原子越好最后的问题： 如果接入一个SDK ，SDK提供的接口有很多个类，一会是类A 一会是类D ，那肯定被骂死。有没有最简单的统一的接口，能不能给客户一个最直接的接口? 所以，这里就有了第6个原则： 最少知识原则，也叫迪米特原则，也就是说，一个类应该对自己需要耦合使用的类知道得越少越好，不要搞那么多乱七八糟的，太不清晰了
至此，我们通过问题引出了6大原则。
接下来，围绕6大原则，有23个具体应用的模式，从用途上，他们可以分为 建造型、结构型以及行为型：
3、建造型模式
4、结构型模式
5、行为型模式
