设计模式代表了最佳的实践，通常是有经验的面向对象的开发人员所采用的，是开发人员在软件开发过程中面临一般问题的解决方案，是众多经验丰富的程序员经过相当长的一段时间的试验和错误总结出来的。熟悉了设计模式，是对自己代码设计的一个升华，所以近段时间的学习就以这个结尾吧。
很早之前就读过一本设计模式的入门书籍——《HeadFirst 设计模式》，但是仅仅是通过书上的一些简单的例子，知晓并了解各种设计模式，很少看到过现实中的代码实现。没有具体的实现，学习设计模式都是空白的。近段时间学习JUC、Spring、Mybatis、Dubbo源码目的是为了熟悉实现原理，并没有具体研究里面用到的设计模式。
所以，接下来的设计模式再入门，也可以当做是之前学习源码的一个复习吧。
一、设计模式的六个原则
大概是我的脑子有问题吧，列出6个原则可能我只会记得原则的名称，时间一长甚至原则的名字都会忘记。所以只列举书上的一些“OO原则”，具体的六个原则，忘记时再去百度吧。
- 封装变化。找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。
- 针对接口编程，不针对实现编程。
- 多用组合少用继承。
- 要依赖于抽象，不要依赖于具体类。
- 为了交互对象之间的松耦合设计而努力。
- 类应该对扩展开放，对修改关闭。
- 只和朋友交谈。（最少知道原则）
- 别找我，我会找你
- 类应该只有一个改变的理由
二、设计模式的分类
设计模式总共有23种，可分为3类。了解一下就行了，背不下来。
1、创建型模式。共五种：工厂模式、抽象工厂模式、单例模式、建造者模式、原型模式。
2、结构型模式（对象之间组合复用）。共七种：适配器模式、装饰器模式、代理模式、外观模式（门面模式）、桥接模式、组合模式、享元模式。
3、行为型模式（对象之间交流）。共十一种：策略模式、观察者模式、模板模式、责任链模式、迭代模式、命令模式、状态模式、访问者模式、中介者模式、解释器模式、备忘录模式
23种设计模式，全部掌握有点不合实际，入门跟着书走，介绍下接下来会学习的设计模式（目录）。
- 策略模式：定义了算法族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化对于使用算法的客户。
- 观察者模式：定义了对象之间的一对多依赖，这样一来，当一个对象改变状态时，它的所有依赖者都会受到通知并自动更新。
- 装饰者模式：动态地将责任附加到对象上去，若要扩展功能，装饰着提供了比继承更有弹性的替代方案。
- 工厂方法模式：抽象父类中对象的创建，用子类来具体实现，使类的实例化推迟到子类。
- 抽象工厂模式：提供一个接口用于创建相关或依赖对象的家族，而不需要明确指定具体类。
- 单例模式：确保一个类只有一个实例。
- 建造者模式：它可以将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象。
- 命令模式：将请求包装成一个对象,这可以让你使用不同的请求，队列，或者日志请求来参数化其他对象。命令模式也可以支持撤销操作。（请求端与服务端解耦mq）
- 适配器模式：将一个类的接口转换成客户期望的另一个接口。适配器让原本接口不兼容的类可以合作无间。
- 外观模式：提供·一个统一的接口，用来访问子系统中的一群接口。定义一个外观的接口，封装了一系列操作，最少知道原则，降低了客户与具体实现类的耦合。
- 模板方法：在一个方法中定义一个算法的骨架（执行顺序），而将一些步骤延迟到子类中，模板方法还可以使得子类可以在不改变算法结构的情况下。重新定义算法中的某些步骤。
- 迭代器模式：提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表达。
- 组合模式：允许你将对象组成树形结构来表现整体部分的层次结构，组合能让客户以一致的方式处理个别对象和对象组合。
- 状态模式：允许对象在内部状态改变时改变他的行为，对象看起来好像修改了它的类。
- 代理模式：为另一个对象提供一个替身或者占位符以控制对这个对象的访问。
三、补充
OO的基础：抽象、封装、多态、继承。
知道OO的基础，并不足以设计出良好的OO系统。
良好的OO系统必须具备可复用、可扩充、可维护三个特性。
模式可以让我们建造出具有良好OO设计质量的系统。
模式被认为是历经验证的OO设计经验。
模式不是代码，而是针对设计问题的通用解决方案。你可把它们应用到特定的应用中。
模式不是被发明，而是被发现
大多数的模式和原则，都着眼于软件变化的主题。
大多数的模式都允许系统局部改变独立于其他部分。
我们常把系统中会变化的部分抽出来封装
模式让开发人员之间有共享的语言，能够最大化沟通的价值。