什么是设计模式
设计模式是人们在面对同类型软件工程设计问题所总结出的一些有用经验。 模式不是代码，而是某类问题的通用设计解决方案。他的本质目的是使软件工程在维护性、 扩展性、 变化性、 复杂度方面成O(N)。OO（面向对象）是原则，设计模式是具体方法和工具。
根据目的、用途的不同，可分为创建性模式、结构性模式、行为性模式。创建型模式主要用于创建对象，结构型模式主要用于处理类和对象的组合，行为性模式主要用于描述类或对象的交互以及职责分配。
根据处理范围不同，又可分为类模式和对象模式，类模式处理类与子类的关系，通过处理这些关系来建立继承，属于静态关系，在编译时候确定下来；对象模式处理对象之间的关系，运行时发生变化，属于动态关系。
如何学好设计模式？
在你的设计和以往的工程里寻找何处可以使用它们。
具体分析方法如下：
场景：项目环境
问题：约束条件，项目目标等
模式：在某些场景下，针对某类问题的某种通用解决方案
解决方案：通用、可以复用的设计，解决约束，达到目标
对象设计七大原则
单一职责原则
类应该只有一个导致类变更的理由，即一个类只负责一项职责。其目的如下：
- 降低类的复杂度
- 提高系统的可维护性
- 修改时降低风险溢出
开闭原则
用抽象构建框架，用实现扩展细节。不以改动原有类的方式来实现新需求，而是应该以实现事先抽象出来的接口（或具体类继承抽象类）的方式来实现。
- 对扩展开放，对修改关闭
- 通过扩展已有软件系统，可以提供新的功能
- 对修改关闭，可以保证稳定性和延续性
组合复用原则
优先使用组合，使系统更灵活，其次才考虑继承，达到复用的目的。
- 多用组合，少用继承
- 找到变化部分，抽象，封装变化
- 区分“Has-A”与“Is-A”
迪米特法则（最少知道法则）
- 一个对象应该与其他对象保持最少的了解，只与直接朋友交谈
- 成员变量、方法参数、方法返回值中需要的类为直接朋友
- 类与类之间的关系越密切了解越多，耦合度越大
- 尽量降低类与类之间的耦合(外观模式、中介者模式)
接口隔离原则
客户端需要什么接口就提供什么接口，把不需要的接口剔除掉，这就需要对接口进行细化，保证接口的纯洁性。
换成另一种说法就是，类间的依赖关系应该建立在最小的接口上，也就是建立单一的接口。
里氏替换原则
- 所有引用基类的地方必须能透明地使用其子类对象，也就是说子类对象可以替换其父类对象，而程序执行效果不变。
- 子类在扩展父类功能时不能破坏父类原有的功能
- 当子类重载父类方法时，方法的形参要比父类方法的参数更宽松
- 当子类实现父类的抽象方法时，方法的返回值要比父类更严格
里氏替换原则是设计整个继承体系的原则，使用继承时，应遵循里氏替换原则（子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。）
定义解读
在继承体系中，子类中可以增加自己特有的方法，也可以实现父类的抽象方法，但是不能重写父类的非抽象方法，否则该继承关系就不是一个正确的继承关系。
优点
可以检验继承使用的正确性，约束继承在使用上的泛滥。
依赖倒置原则
- 成员变量、方法参数、返回值要依赖于抽象，不要依赖于具体
- 高层模块不应该依赖低层模块，二者都应该依赖其抽象
- 抽象不应该依赖具体，具体应该依赖抽象
定义解读
- 要针对接口编程，不要针对实现编程（以抽象为基础搭建的结构比具体类搭建的结构要稳定的多，在java中，抽象指的是接口或者抽象类，具体就是具体的实现类。）
- 尽量不要从具体的类派生，而是以继承抽象类或实现接口来实现。
- 关于高层模块与低层模块的划分可以按照决策能力的高低进行划分。业务层自然就处于上层模块，逻辑层和数据层自然就归类为底层。
优点
通过抽象来搭建框架，建立类和类的关联，以减少类间的耦合性，而且以抽象搭建的系统要比以具体实现搭建的系统更加稳定，扩展性更高，同时也便于维护。
设计模式的三大分类
- 创建型模式：对象实例化的模式，解耦对象的实例化过程
- 结构型模式：把类或对象结合在一起形成更大的结构
- 行为型模式：类和对象如何交互，及划分责任和算法
各分类中模式的关键点
创建型模式
用于创建对象，关注对象的创建过程
- 简单工厂：一个工厂类根据传入的参量决定创建出哪一种产品类的实例
- 工厂方法：定义一个创建对象的接口，让子类决定实例化哪一个类
- 抽象工厂：创建相关或依赖对象的家族，而无需明确指定具体类
- 单例模式：某个类只能有一个实例，提供一个全局访问点
- 生成器模式/建造者模式：封装一个复杂对象的构建过程，并可以按步骤构造
- 原型模式：通过复制现有的实例来创建新的实例
结构型模式
用于处理类和对象的组合，关注对象和类的组织
- 适配器模式：将一个类的方法接口转换成客户希望的另外一个接口
- 组合模式：将对象组合成树形结构以表示“部分-整体”的层次结构
- 装饰模式：动态地给对象添加新的功能，样例
- 代理模式：为其他对象提供一个代理以控制对这个对象的访问，样例
- 蝇量模式(享元模式)：通过共享技术有效地支持大量细粒度的对象
- 外观模式：提供统一的方法来访问子系统的一群接口
- 桥接模式：将抽象部分与它的实现部分分离，使它们都可以独立地变化
行为型模式
用于描述类或对象的交互以及职责分配。关注系统中对象的相互交互，研究系统在运行时对象之间的相互通信和协作，进一步明确对象的职责
- 模板模式：定义一个算法结构，而将一些步骤延迟到子类中实现，样例
- 解释器模式：给定一个语言， 定义它的文法的一种表示，并定义一个解释器
- 策略模式：定义一系列的算法，把它们封装起来， 并且使它们可相互替换，样例1，样例2
- 状态模式：允许一个对象在其内部状态改变时改变它的行为，样例
- 观测者模式：对象间的一对多的依赖关系
- 备忘录模式：在不破坏封装性的前提下，保存对象的内部状态
- 中介者模式：用一个中介对象来封装一系列的对象交互
- 命令模式：将命令请求封装为一个对象，使得可用不同的请求来进行参数化，样例
- 访问者模式：在不改变数据结构的前提下，增加作用于一组对象元素新的功能
- 责任链：请求发送者和接收者之间解耦，使的多个对象都有机会处理这个请求，样例
- 迭代器：一种遍历访问聚合对象中各个元素的方法，不暴露该对象的内部结构
用设计模式来思考问题
尽量保持简单
- 尽可能用最简单的方式解决问题
- 简单而弹性的设计，一般使用模式是最好的方法
设计模式并非万能
- 模式是通用问题的经验总结
- 使用模式时要考虑它对其他部分的影响
- 不需要预留任何弹性的时候，删除掉模式
- 解决问题是需要考虑平衡与妥协
何时需要设计模式?
- 找出设计中会变化的部分，这通常就是需要考虑模式的地方
- 重构时需要考虑设计模式，重构的时间就是模式的时间、重构就是通过改变代码来改进组织方式的过程、利用设计模式来进行重构
