模式比较
3.1 State模式和Strategy模式
1. State模式和Strategy模式又很大程度上的相似：它们都有一个Context类，都是通过委托（组合）给一个具有多个派生类的多态基类实现Context的算法逻辑。
2. 两者最大的差别就是State模式中派生类持有指向Context对象的引用，并通过这个引用调用Context中的方法，但在Strategy模式中就没有这种情况。因此可以说一个State实例同样是Strategy模式的一个实例，反之却不成立。
3. 实际上State模式和Strategy模式的区别还在于它们所关注的点不尽相同：State模式主要是要适应对象对于状态改变时的不同处理策略的实现，而Strategy则主要是具体算法和实现接口的解耦（coupling），Strategy模式中并没有状态的概念（虽然很多时候有可以被看作是状态的概念），并且更加不关心状态的改变了。
4. State模式很好地实现了对象的状态逻辑和动作实现的分离，状态逻辑分布在State的派生类中实现，而动作实现则可以放在Context类中实现（这也是为什么State派生类需要拥有一个指向Context的指针）。这使得两者的变化相互独立，改变State的状态逻辑可以很容易复用Context的动作，也可以在不影响State派生类的前提下创建Context的子类来更改或替换动作实现。
3.2 Template模式和Strategy模式
可以看到Strategy模式和Template模式解决了类似的问题，也正如在Template模式中分析的，Strategy模式和Template模式实际是实现一个抽象接口的两种方式：继承和组合之间的区别。
要实现一个抽象接口，继承是一种方式：我们将抽象接口声明在基类中，将具体的实现放在具体子类中。组合（委托）是另外一种方式：我们将接口的实现放在被组合对象中，将抽象接口放在组合类中。这两种方式各有优缺点，先列出来:
继承
优点：
（1） 易于修改和扩展那些被复用的实现。
缺点
（1） 破坏了封装性，继承中父类的实现细节暴露给子类了
（2） “白盒”复用，原因在1）中
（3） 当父类的实现更改时，其所有子类将不得不随之改变
（4） 从父类继承而来的实现在运行期间不能改变（编译期间就已经确定了）
组合
优点：
（1） “黑盒”复用，因为被包含对象的内部细节对外是不可见的。
（2） 封装性好，原因为1）
（3） 实现和抽象的依赖性很小（组合对象和被组合对象之间的依赖性小）
（4） 可以在运行期间动态定义实现（通过一个指向相同类型的指针，典型的是抽象基类的指针）
缺点
（1） 系统中对象过多
从上面对比中我们可以看出，组合相比继承可以取得更好的效果，因此在面向对象的设计中的有一条很重要的原则就是：优先使用（对象）组合，而非（类）继承（Favor Composition Over Inheritance）。
实际上，继承是一种强制性很强的方式，因此也使得基类和具体子类之间的耦合性很强。例如在Template模式中在ConcreteClass1中定义的原语操作别的类是不能够直接复用（除非你继承自AbstractClass，具体分析请参看Template模式文档）。而组合（委托）的方式则有很小的耦合性，实现（具体实现）和接口（抽象接口）之间的依赖性很小，例如在本实现中，ConcreteStrategyA的具体实现操作很容易被别的类复用，例如我们要定义另一个Context类AnotherContext，只要组合一个指向Strategy的指针就可以很容易地复用ConcreteStrategyA的实现了
Template模式暴露的问题也正是继承所固有的问题，Strategy模式则通过组合（委托）来达到和Template模式类似的效果，其代价就是空间和时间上的代价
3.3 Factory模式和AbstractFactory模式
1 Abstract Factory模式和Factory最大的差别就是抽象工厂创建的是一系列相关的对象,其中创建的实现其实采用的就是Factory模式的方法,对于某个实现的有一个派生出来的抽象工厂,另一个实现有另一个派生出来的工厂,等等。
2 可以举一个简单的例子来解释这个模式:比如,同样是鸡腿(ProductA)和汉堡(ProductB),它们都可以有商店出售(AbstractFactory),但是有不同的实现,有肯德基(ConcreateFactory1)和麦当劳(ConcreateFactory2)两家生产出来的不同风味的鸡腿和汉堡(也就是ProductA 和ProductB的不同实现).而负责生产汉堡和鸡腿的就是之前提过的Factory模式了.抽象工厂需要特别注意的地方就是区分不同类型的产品和这些产品的不同实现.显而易见的,如果有n种产品同时有m中不同的实现,那么根据乘法原理可知有n*m个Factory模式的使用。
3 AbstractFactory模式和Factory模式的区别是初学（使用）设计模式时候的一个容易引起困惑的地方。实际上，AbstractFactory模式是为创建一组（有多类）相关或依赖的对象提供创建接口，而Factory模式正如我在相应的文档中分析的是为一类对象提供创建接口或延迟对象的创建到子类中实现。并且可以看到，AbstractFactory模式通常都是使用Factory模式实现（ConcreteFactory1）。
3.4 Composite模式和Decorator模式
Composite模式通过和Decorator模式有着类似的结构图，但是Composite模式旨在构造类，而Decorator模式重在不生成子类即可给对象添加职责。Decorator模式重在修饰，而Composite模式重在表示。
3.5 Proxy模式和Decorator模式
1 Decorator模式和Composite模式有相似的结构图，其区别在Composite模式已经详细讨论过了，请参看相应文档。另外GoF在《设计模式》中也讨论到Decorator和Proxy模式有很大程度上的相似，初学设计模式可能实在看不出这之间的一个联系和相似，并且它们在结构图上也很不相似。实际上，在本文档2.2节模式选择中分析到，让Decorator直接拥有一个ConcreteComponent的引用（指针）也可以达到修饰的功能，大家再把这种方式的结构图画出来，就和Proxy很相似了！
2 Decorator模式和Proxy模式的相似的地方在于它们都拥有一个指向其他对象的引用（指针），即通过组合的方式来为对象提供更多操作（或者Decorator模式）间接性（Proxy模式）。但是他们的区别是，Proxy模式会提供使用其作为代理的对象一样接口，使用代理类将其操作都委托给Proxy直接进行。这里可以简单理解为组合和委托之间的微妙的区别了。
3.6 State模式，Strategy模式和FlyWeight模式
我们在State模式和Strategy模式中会产生很多的对象，因此我们可以通过Flyweight模式来解决这个问题
3.7 Bridge模式和Builder模式
1. Bridge的实现方式其实和Builde十分的相近,可以这么说:本质上是一样的,只是封装的东西不一样罢了.两者的实现都有如下的共同点:抽象出来一个基类,这个基类里面定义了共有的一些行为,形成接口函数(对接口编程而不是对实现编程),这个接口函数在Buildier中是BuildePart函数在Bridge中是OperationImpl 函数;其次,聚合一个基类的指针,如Builder模式中Director类聚合了一个Builder基类的指针,而Bridge模式中Abstraction类聚合了一个Implementor基类的指针(优先采用聚合而不是继承);而在使用的时候,都把对这个类的使用封装在一个函数中,在Bridge中是封装在Director::Construct函数中,因为装配不同部分的过程是一致的,而在Bridge模式中则是封装在Abstraction::Operation函数中,在这个函数中调用对应的Implementor::OperationImpl函数.就两个模式而言,Builder封装了不同的生成组成部分的方式,而Bridge封装了不同的实现方式。
2. 因此,如果以一些最基本的面向对象的设计原则来分析这些模式的实现的话,还是可以看到很多共同的地方的
3.8 Builder，Prototype和AbstractFactory模式
1. Builder模式重在复杂对象的一步步创建（并不直接返回对象），AbstractFactory模式重在产生多个相互依赖类的对象，而Prototype模式重在从自身复制自己创建新类
2. Builder模式和AbstractFactory模式在功能上很相似，因为都是用来创建大的复杂的对象，它们的区别是：Builder模式强调的是一步步创建对象，并通过相同的创建过程可以获得不同的结果对象，一般来说Builder模式中对象不是直接返回的。而在AbstractFactory模式中对象是直接返回的，AbstractFactory模式强调的是为创建多个相互依赖的对象提供一个同一的接口。
