Where am I
目录
00 引言
000 什么是设计模式？
每一个模式描述了一个在我们周围不断重复发生的问题， 以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。
- 重复发生的问题
- 问题解决方案的核心
- 复用成熟的解决方案，减少重复的劳动
001 如何详细描述某一设计模式？
| 描述角度 | 说明 |
|---|---|
| 意图 | 通过什么方法解决什么样的特定设计问题 |
| 别名 | 模式的其他名称 |
| 动机 | 实现意图的基础、基本原理，说明一个模式中的类、对象如何解决特定的设计问题 |
| 适用性 | 什么情况下可以使用该设计模式？该设计模式可以用来改良哪些不良设计？我们怎样识别这些情况？ |
| 参与者 | 指设计模式中的类或对象以及它们各自的职责 |
| 协作 | 模式的参与者怎样协作以实现它们的职责 |
| 结构 | 采用基于对象建模技术的表示法对模式中的类进行图形描述 |
| 效果 | 模式怎样支持它的目标？使用模式的效果和所需做的权衡取舍？系统结构的哪些方面可以独立改变？ |
| 实现 | 实现模式时需要知道的一些提示、技术要点及应避免的缺陷，以及是否存在某些特定于实现语言的问题 |
| 已知应用 | 实际系统中发现的模式的例子。每个模式至少包括了两个不同领域的实例 |
| 代码示例 | 用来说明怎样实现该模式的代码片段 |
| 相关模式 | 与这个模式紧密相关的模式有哪些？其间重要的不同之处是什么？这个模式应与哪些其他模式一起使用？ |
002 设计模式分类
分类准则
| 分类准则 | 类型 | 类型描述 |
|---|---|---|
| 目的 | 创建型 | 与对象的创建有关 |
| 目的 | 结构型 | 处理类或对象的组合 |
| 目的 | 行为型 | 对类或对象怎样交互和怎样分配职责进行描述 |
| 范围 | 类 | 处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了 |
| 范围 | 对象 | 处理对象间的关系，这些关系在运行时刻是可以变化的，更具动态性 |
分类结果
| 类型名称 | 类型描述 | 具体设计模式 | 设计模式描述 |
|---|---|---|---|
| 创建型类模式 | 将对象的部分创建工作延迟到子类 | ||
| 工厂方法模式 | 定义一个用于创建对象的接口，让子类决定将哪一个类实例化 | ||
| 创建型对象模式 | 将对象的部分创建工作延迟到另一个对象 | ||
| 抽象工厂模式 | 提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类 | ||
| 建造者模式 | 将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示 | ||
| 原型模式 | 用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象 | ||
| 单例模式 | 保证一个类仅有一个实例，并提供一个访问它的全局访问点 | ||
| 结构型类模式 | 使用继承机制来组合类 | ||
| 适配器模式（类） | 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作 | ||
| 结构型对象模式 | 描述了对象的组装方式 | ||
| 适配器模式（对象） | 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作 | ||
| 桥接模式 | 将抽象部分与它的实现部分分离，使它们都可以独立地变化 | ||
| 组合模式 | 将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得客户对单个对象和复合对象的使用具有一致性 | ||
| 装饰器模式 | 动态地给一个对象添加一些额外的职责。就扩展功能而言，Decorator模式比生成子类方式更为灵活 | ||
| 外观模式 | 为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用 | ||
| 享元模式 | 运用共享技术有效地支持大量细粒度的对象 | ||
| 代理模式 | 为其他对象提供一个代理以控制对这个对象的访问 | ||
| 类行为型 | 使用继承描述算法和控制流 | ||
| 解释器模式 | 给定一个语言,定义它的文法的一种表示，并定义一个解释器,该解释器使用该表示来解释语言中的句子 | ||
| 模板方法模式 | 定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。TemplateMethod使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤 | ||
| 对象行为型 | 描述一组对象怎样协作完成单个对象所无法完成的任务 | ||
| 职责链模式 | 为解除请求的发送者和接收者之间耦合，而使多个对象都有机会处理这个请求。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它 | ||
| 命令模式 | 将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志，以及支持可取消的操作 | ||
| 迭代器模式 | 提供一种方法顺序访问一个聚合对象中各个元素,而又不需暴露该对象的内部表示 | ||
| 中介者模式 | 用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互 | ||
| 备忘录模式 | 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到保存的状态 | ||
| 观察者模式 | 定义对象间的一种一对多的依赖关系,以便当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并自动刷新 | ||
| 状态模式 | 允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类 | ||
| 策略模式 | 定义一系列的算法,把它们一个个封装起来,并且使它们可相互替换。本模式使得算法的变化可独立于使用它的客户 | ||
| 访问者模式 | 表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作 |
003 常见导致重新设计的场景
| 场景 | 场景描述 | 解决方案 |
|---|---|---|
| 通过显式地指定一个类来创建对象 | 在创建对象时指定类名将使你受特定实现的约束而不是特定接口的约束。这会使未来的变化更复杂。要避免这种情况，应该间接地创建对象 | 抽象工厂模式 工厂方法模式 原型模式 |
| 对特殊操作的依赖 | 当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。为避免把请求代码写死，你将可以在编译时刻或运行时刻很方便地改变响应请求的方法 | 职责链模式 命令模式 |
| 对硬件和软件平台的依赖 | 外部的操作系统接口和应用编程接口(API)在不同的软硬件平台上是不同的。依赖于特定平台的软件将很难移植到其他平台上，甚至都很难跟上本地平台的更新。所以设计系统时限制其平台相关性就很重要了 | 抽象工厂模式 桥接模式 |
| 对对象表示或实现的依赖 | 知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化 | 抽象工厂模式 桥接模式 备忘录模式 代理模式 |
| 算法依赖算法在开发和复用时常常被扩展、优化和替代 | 依赖于某个特定算法的对象在算法发生变化时不得不变化。因此有可能发生变化的算法应该被孤立起来 | 建造者模式 迭代器模式 策略模式 模板方法模式 访问者模式 |
| 紧耦合紧耦合的类很难独立地被复用，因为它们是互相依赖的 | 紧耦合产生单块的系统，要改变或删掉一个类，你必须理解和改变其他许多类。这样的系统是一个很难学习、移植和维护的密集体。 松散耦合提高了一个类本身被复用的可能性，并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性 | 抽象工厂模式 命令模式 外观模式 中介者模式 观察者模式 职责链模式 |
| 通过生成子类来扩充功能通常很难通过定义子类来定制对象 | 每一个新类都有固定的实现开销(初始化、终止处理等)。定义子类还需要对父类有深入的了解。如，重定义一个操作可能需要重定义其他操作。一个被重定义的操作可能需要调用继承下来的操作。并且子类方法会导致类爆炸，因为即使对于一个简单的扩充，你也不得不引入许多新的子类。 一般的对象组合技术和具体的委托技术，是继承之外组合对象行为的另一种灵活方法。新的功能可以通过以新的方式组合已有对象，而不是通过定义已存在类的子类的方式加到应用中去。另一方面，过多使用对象组合会使设计难于理解。许多设计模式产生的设计中，你可以定义一个子类，且将它的实例和已存在实例进行组合来引入定制的功能 | 桥接模式 职责链模式 组合模式 装饰器模式 观察者模式 策略模式 |
| 不能方便地对类进行修改有时你不得不改变一个难以修改的类 | 也许你需要源代码而又没有(对于商业类库就有这种情况)，或者可能对类的任何改变会要求修改许多已存在的其他子类。设计模式提供在这些情况下对类进行修改的方法 | 适配器模式 装饰器模式 访问者模式 |
004 使用设计模式存在的缺陷
设计模式引入额外的间接层次获得灵活性和可变性的同时，也使设计变得更复杂或牺牲了一定的性能。一个设计模式只有当它提供的灵活性是真正需要的时候，才有必要使用。
