阅读量:0
引言
设计模式的宗旨是帮助我们管理变化，提高代码复用。好的设计模式，可以让我们的代码层次更加清晰，便于管理和迭代。所以设计模式应该是每个程序员的必修课。
设计模式8大原则
- 开放封闭
- 依赖倒置
- 里氏替换
- 单一职责
- 接口隔离
- 对象组合优于类继承
- 封装变化点
- 面向接口编程
具体原则的定义请参考此处
23种设计模式
以下分类方式是课程老师为了方便理解进行划分的，不代表业界划分规则。
1. 组件协作
- 模板方法
定义一个操作中的算法骨架（稳定的），而将一些步骤的实现延迟到子类中（变化的）。模板方法使得子类可以复用一个算法的结构，而只改变（重写）这个算法的特定步骤。 - 策略模式
定义一些列算法，把他们一个个封装起来，并且使他们可以相互替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展、子类化）。 - 观察者模式
观察者模式又叫发布-订阅模式。定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个目标对象。这个对象在状态发生变化时，会通知所有观察者对象，使他们能够自动更新自己。
2. 单一职责
- 装饰模式
动态地给一个对象添加一些额外的职责，就增加功能来说，装饰模式比生成子类更为灵活。装饰模式属于结构型模式，它是作为现有的类的一个包装。 - 桥接模式
桥接模式是一种结构型设计模式，它将抽象部分与其实现部分分离，使它们都可以独立变化。这种模式有时也被称作柄体(Handle and Body)模式或接口隔离模式。它的主要目的是将抽象层与实现层解耦，使得两者可以独立扩展而互不影响。
3. 对象创建
- 工厂方法
通过定义工厂，父类负责定义创建对象的公共接口，而子类则负责生成具体的对象。 - 抽象工厂
提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。 - 原型模式
用原型实例指定创建对象的种类，并通过拷贝这些原型创建新的对象，简单理解就是“克隆指定对象” - 构建器模式
将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
4. 对象性能
- 单例模式
整个系统中只有一个该类的对象实例，不再有第二个实例。 - 享元模式
享元模式主要用于减少创建对象的数量，以减少内存占用和提高性能。这种类型的设计模式属于结构型模式，它提供了减少对象数量从而改善应用所需的对象结构的方式。
5. 接口隔离
- 门面模式
它要求一个子系统的的外部与其内部的通信必须通过一个统一的接口对象进行，门面模式定义一个高层次的接口，使子系统更易于使用。 - 代理模式
我们使用代理对象来代替对真实对象(real object)的访问，这样就可以在不修改原目标对象的前提下，提供额外的功能操作，扩展目标对象的功能。 - 中介者模式
用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式，它是一种对象行为型模式。 - 适配器模式
适配器模式是一种结构型设计模式，它允许将不兼容的对象转换成可兼容的接口。主要目的是解决在不改变现有代码的情况下，使不兼容的接口之间能够正常工作，通过创建一个中间转换的适配器来将一个对象转换成我们所需要的接口。
6. 状态变化
- 状态模式
状态模式把受环境改变的对象行为包装在不同的状态对象里，其意图是让一个对象在其内部状态改变的时候，其行为也随之改变。 - 备忘录模式
在不破坏封装的前提下，捕获一个对象的内部状态，并在对象之外保存这个状态，这样我们就可以在需要的时候将该对象恢复到原先保存的状态了，备忘录模式属于行为型模式。
7. 数据结构
- 组合模式
将对象组合成树形结构, 表示 " 部分-整体 " 层次结构，组合模式使客户端对单个对象和组合对象保持一致的处理方式。 - 迭代器模式
迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露其内部的表示。 - 职责链模式
避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止，属于对象行为模式。
8. 行为变化
- 命令模式
将一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。 - 访问者模式
访问者模式是一种行为设计模式，它表示一个作用于某对象结构中的各个元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式适用于需要对一个对象结构中的对象进行很多不同类型的运算，而且施加运算的对象又不希望知道这些运算的具体实现的情况。
9. 领域问题
- 解析器模式
给定一个语言, 定义它的文法的一种表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。
总结
设计模式的目标是管理变化，提高代码复用。在使用模式的时候，应该非常明确需求的变化点与稳定点，否则设计模式不一定适用。另外，设计模式给予我们的只是一个参考，我们更应该关注和掌握的是设计原则，有了对设计原则的深刻理解，在设计代码的过程中，我们也能设计出适合我们自己业务场景的设计模式，这才是学习设计模式最终应该达到的层次。
