多种设计模式的对比

1.工厂方法模式

当client不知道要创建哪个具体类的实例，或者不想在client代码中指明要具体创建的实例时，用工厂方法。

定义一个用于创建对象的接口，让其子类来决定实例化哪一个类，从而使一个类的实例化延迟到其子类。

优点：

消除了将特定于应用程序的类绑定到代码的需要。

代码仅处理产品接口（Trace），因此它可以与任何用户定义的ConcreteProduct（FileTrace，SystemTrace）一起使用

潜在的缺点

客户必须创建Creator的子类，以便他们可以创建某个ConcreteProduct。

如果客户无论如何都要继承创造者的话，这是可以接受的，但如果不是，那么客户必须处理另一个进化点。

2.抽象工厂模式

抽象工厂创建的不是一个完整产品，而是“产品族”（遵循固定搭配规则的多类 产品的实例 ），得到的结果是：多个不同产品 的object ，各产品创建过程对client 可见，但“搭配”不能改变 。

3.抽象工厂 vs 工厂方法

工厂方法仅用于创建一个产品，但抽象工厂则用于创建相关产品或相关产品的族。

工厂方法模式向客户端公开了创建对象的方法，而抽象工厂公开了由这些工厂方法组成的一系列相关对象。

抽象工厂模式使用组合来将创建对象的责任委派给另一个类，而工厂方法模式使用继承并依赖于派生类或子类来创建对象。

4.构造器模式

将复杂对象的构造与其表示分开，以便相同的构建过程可以创建不同的表示。

注意：client要的不是一堆零散的objects (abstract factory那样的结果)，而是一个完整的产品，client不关心其中的细节组成部分是什么、如何创建。

5.抽象工厂 vs 构造器

Abstract Factory创建的不是一个完整产品，而是“产品族”（遵循 固定搭配规则的多类产品实例），得到的结果是：多个不同产品的实例object，各产品创建过程对client可见，但“搭配”不能改变。

Builder创建的是一个完整的产品，有多个部分组成，client不需了解每个部分是怎么创建、各个部分怎么组合，最终得到一个产品的完整 object 。

6.模板方法 vs 构造器

Template Method: a behavioral pattern 目标是为了复用算法的公共结构（次序）。

• 定义了一个操作中算法的骨架(steps)，而将具体步骤的实现延迟到子类中， 从而复用算法的结构并可重新定义算法某些特定步骤的实现逻辑。
• 复用算法骨架，强调步骤的次序
• 子类override算法步骤

Builder: a creationalpattern 目标是“创建复杂对象”，灵活扩展

• 将一个复杂对象的构造方法与对象内部的具体表示分离出来，同样的构造方法可以建立不同的表现。
• 不强调复杂对象内部各部分的“次序”
• 子类override复杂对象内部各部分的“创建”
• 适应变化：通过派生新的builder来构造新的对象（即新的内部表示），OCP

7.桥接模式 vs. 策略模式

Bridge: structural pattern 强调双方的run time delegation linking ：

一个类A的对象中有其他类B的对象作为其组成部分，但A的对象具体绑定到B的哪个具体子类的实现？在运行时通过delegation加以组合， 并永久保存这种delegation关系。

Bridge强调结构关系的动态绑定，举例来说，类A需要完成“通讯”功能，它有一个组成部分Device类，这是个抽象接口（模式中的implementor），有多种实现方式（PC, tablet, phone，即ConcreteImplementor），该模式在运行时为类A的具体子类型实例设定具体的Device的具体实现（强调对A和Device两个抽象类的各自实例之间如何建立delegation），进而在其他各项功能中利用其通讯功能（这不再是bridge关注的目标）。

Strategy: behavioral pattern 强调一方run-time使用另一方的“算法” ：

“算法”通常实现为“类的某个方法”的形式，strategy的目的并非在“调用算法的类”与“被调用算法所在的类”之间建立起永久联系，而只是帮助前者临时使用后者中的“算法”，前者无需永久保存后者的实例。

举例子来说，Strategy强调算法的动态调用，但前提是动态绑定。使用螺丝刀的时候，针对不同的工作任务，选取不同的“刀头”，但目的并非将 螺丝刀与刀头组合起来建立永久的delegation， 而只是临时通过delegation完成任务（即调用刀 头的“算法”），然后二者再无联系。

8.代理模式 vs 适配器模式

适配器：结构模式，目的是将类/库A的接口更改为客户端B的期望。

目的：消除不兼容，目的是B以客户端期望的统一的方式与A建立起联系。

代理模式：行为模式，也使用包装类，但其目的是为实际资源创建一个替身。

目的：隔离对复杂对象的访问，降低难度/代价，定位在“访问/使用行为”。

9.组合模式 vs 装饰器

组合模式：结构模式，允许以外部代码将整个结构视为单个实体的方式构建分层结构（树）。
目的是在同类型的对象之间建立起树型层次结构，一个上层对象可包含多个下层对象

装饰器：结构模式，也允许一个实体完全包含另一个实体，以便使用装饰器看起来与包含的实体相同。
强调的是同类型对象之间的“特性增加”问题，它们之间是平等的，区别在于“拥有特性”的多少，每次装饰只能作用于一个对象。

10.Visitor vs Iterator

迭代器：行为模式，以遍历的方式访问集合数据而无需暴露其内部表示，将“遍历”这项功能delegate到外部的iterator对象。

访问者：行为模式，用于对元素结构执行操作而不改变元素本身的实现。在特定ADT上执行某种特定操作，但该操作不在ADT内部实现，而是delegate到独立的visitor对象，客户端可灵活扩展/改变visitor的操作算法，而不影响ADT

11.Strategy vs visitor

二者都是通过delegation 建立两个对象的动态联系
但是Visitor强调是的外部定义某种对ADT的操作，该操作于ADT自身关系不大（只是访问ADT），故ADT内部只需要开放accept(visitor)即可，client通过它设定visitor操作并在外部调用。
Strategy则强调是对ADT内部某些要实现的功能的相应算法的灵活替换。这些算法是ADT功能的重要组成部分，只不过是delegate到外部strategy类而已。

12.Observer vs Mediator

观察者模式：定义对象之间的一对多依赖关系，以便当一个对象改变状态时，它的所有依赖项都会被自动通知和更新。

一组object对另一个object B的状态变化感兴趣（1对多），所以对其进行观察。B维持着一个对自己感兴趣的object list，一旦自己发生变化，就通知这些object。双方地位并不对等，一方只是“通知”，另一方接到通知后执行特定行为。

Mediator模式：定义一个封装一组对象如何交互的对象。 介体通过让对象明确地互相引用来促进松散耦合，并且可以让您独立地改变它们的相互作用。一组同类型的object，彼此之间相互发/收消息（多对多），不存在谁观察谁的问题，所有object都对等。每个object都维持一个mediator，将通讯的任务delegate给它，自己只负责send和receive即可，无需了解其他object，实现了“解耦”。

13.Façade vs. Command

Command ：强调将指令封装为了“对象”，提供了统一的对外接口

Façade ：没有显式的“对象”，仍然通过类的方法加以调用

14.Visitor vs. Chain of Responsibility

visitor 只定义了一个操作，chain of responsibility 定义了一组操作及其之间的次序

visitor 中，client 创建visitor 之后传入ADT ，ADT 再 将执行权delegate 到visitor ；chain of responsibility 中，控制权完全在各个handler 之间流转，ADT(request 对象) 完全感受不到。