该栏目以简单易懂为原则，以口水话方式讲解各类设计模式，让即使是未接触过计算机的人通过这系列栏目明白设计模式，一看就懂，看懂就会用。力求简单易懂。
为什么学习设计模式
先不讲设计模式这个概念，这概念网上都有，随便搜搜就一大堆，而且可能更官方、更专业。我想从数学的学习历程的角度去讲。
- 幼儿园：对于 0.1.2.3.4.5.6.7.8.9 这十个数，我们所学习到就只有“加法+”、“减法-”以及“等号=”
- 小学：对于数字范围扩大到十、百、千、万以及亿，所使用到的运算符扩充到乘法、除法，甚至增加了一元一次方程等。
- 初高中：数字范围进一步扩大，往前扩充到负数，运算符增加了幂运算、函数、几何、集合运算等等。
但是呢，这些数字都有特定的运算规则。说到底，数学运算规则就是前人总结的一套模式，一套全世界人都知晓的、反复使用的设计模式。看吧，这设计模式的定义就来了：一套被反复使用的、绝大多数人都知晓的总结，对于计算机领域而言，这套总结能重复使用代码，让代码能更加简介，方便绝大多数人使用的一套总结。
设计模式: 在某些场景下，针对某类问题的通用解决方案
分类
同样，咱也从数字到数学讨论，设计模式的分类。
首先，肯定是先有了数字, 0 1 2 3 ...等等，以及对应的运算符号+ - * /
其次，针对这些数字和符号，进行组合形成一定的结构模型，即方程、函数等
最后，通过这些数字和符号的结构模型，得到一定的运算结果，完成执行的行为动作等等。
因此，设计模式 可以说也是遵从这样的一个脉络，分为三种类型，分别是 创建型模式、结构型模式以及行为型模式，分别负责不同的功能。
创建型模式：对象实例化，用于将抽象对象实例化；
结构型模式：把类或者对象组合到一起形成一个更大的模型；
行为型模式：对象与对象之间的的交互方式，各自承担的责任范围。
六大原则
咱们还是以数字为由头讲，你看哦，数字之间存在大小之分，数字运算需要遵循一定的规则，像先乘除后加减，先算括号内再算括号外等等，当然了，设计模式也需要遵循一定的规则，这些规则也是大家公认都遵守的规则。
单一职责原则
定义：一个类或者模块应用应当有且仅有负责一项职责，即仅有一个引起它变化的原因。
通俗的说，一个类不能承担过多的职责。如果一个类承担的职责过多，那某个职责的变化就可能抑制其他能力，因此过多职责耦合在一起，反而会导致脆弱的设计。
开闭原则
开放封闭原则，对于扩展开放，修改封闭。即在原有基础上进行扩展是支持的，修改原有的逻辑是不支持的。
需求肯定是不断变化的，但是作为开发人员，当然希望尽可能少的修改原有的代码，以避免对于原有逻辑的破坏，保证原有功能的稳定，因此提倡功能的扩展，而非功能的修改，即 扩展开放，修改封闭。
里式替换原则
定义：所有引用基类的地方必须透明使用其子类的对象
代码里都存在父类和子类，其中父类可强制转化为子类，但是子类无法转化为父类；如果在代码中都使用父类对象，在运行时可以根据情况进行转化为子类对象，满足开闭原则，这也就是尽可能用父类的原因，所以尽可能的把父类设计成abstract类或者interface接口，让子类去继承或者实现；运行时，让子类实例替换父类。
依赖倒置原则
定义：高层次不能依赖低层次，抽象不能依赖细节
具体的类直接依赖细节，那么类之间就会直接耦合。如此一来当修改一个实现类时，就会同时修改其依赖的细节类，这样反而限制了实现类的可扩展性。
迪米特法则
定义：一个类应当尽可能少的与其他实体发生相互作用
个人理解，这其实就是对于单一变化原则的佐证，类实体之间发生相互作用的次数少了，那触发改变的可能性就少了，那类具有较好的单一变化原则。
接口分离原则
定义：一个类对另一个类的依赖应该建立在尽可能小的接口上。
建立单一接口，不要建立庞大臃肿的接口；尽量细化接口，接口中的方法尽可能少，否则实现类中额外增加了不需要的函数实现。
总结
很多的设计模式都是在人的经验基础上总结的，需要在实践中不断积累。
