10.Facade（外观、门面）

Facade（外观、门面）

     是外部用户对象通过一个统一的门面的对象来与一个子系统进行交互。门面模式为子系统中的一组接口，提供一个统一的门面供外部对象访问。也就是门面模式定义了一个更高层次的接口让外部对象容易使用这个子系统。

适用情况：

1.想要为一个复杂的子系统提供简单的接口。

2.客户程序与抽象类的实现部分之间存在者很大的依赖性。

3.当需要构建一个层次结构的子系统时，使用门面模式定义子系统中每个曾的入口。如果子系统之间是相互依赖的，则可以让他们仅通过Facade进行通信，从而简化了他们之间的依赖关系。

4.在分布系统中，为了减少客户端进行远程调用的次数，可是使用门面模式来有效的减少远程调用。

结构：

1.门面（CFacade）：门面对象是一个协调者，他知道那个子系统类要相应那些请求，能实现那些功能。他负责吧客户端请求委托给适当的子系统对象。

2.子系统（CSubSystem）：负责实现子系统的功能，他们既可以被门面对象调用，也可以被客户端直接调用。他们不知道门面对象，也无需维护与门面对象的引用。

     门面模式工作时，使用门面对象的客户端无需直接访问子系统对象，而是由门面对象将客户端的请求传递给适当的子系统对象，让子系统对象完成实际的工作。这就是说，由门面对象来调用相关子系统的方法，并把子系统的接口转换成客户端需要的接口。原来客户端需要和多个子系统打交道，现在就变成了客户端只和一个门面对象打交道。这样一来就降低了系统之间的依赖性和复杂性。

9.Decorator（装饰者模式）

Decorator（装饰者模式）

     以对客户端透明的方式动态的为对象附加责任。此模式提供了一个比继承更为灵活的替代方案来扩展对象的功能。虽然与适配器一样的被称作包装者（wrapper）但他们本质有区别。适配器要改变所考虑对象接口，而不一定改变对象的性能；装饰者是要保持对象接口，从而增强对象性能。

适用情况：

1.在不影响其他对象的情况下，动态且透明的增加一个责任到一个对象。

2.希望责任和功能可以随时增加或取消。

3.当无法通过类的继承来扩展功能时。（继承过多；类的定义被隐藏；类的定义不便于生成派生类）

结构：

1.抽象部件（CComponent）：定义一个对象接口，可以动态的附加责任到其他对象上。

2.具体部件（CConcreteComponent）：定义可以被附加责任的对象。

3.装饰者（CDecorator）：维护一个到抽象部件对象的引用，并定义与抽象部件接口一致的接口，以便“装饰”抽象部件对象的接口。

4.具体装饰者（CConcreteDecorator）：附加责任到抽象部件，完成具体的“装饰”。

。。。。

8.Composite（合成模式、个别-整体模式）

Composite（合成模式、个别-整体模式）

     合成模式吧多个对象合称为树状结构用以表现个别与整体的层次结构。合成模式让客户端能够以统一的方式处理单个对象和合成对象。合成模式是一个表示基本元素及其容器的抽象类。

适用情况：

1.要显示对象之间个别与整体的树形结构。

2.要让客户端忽略合成对象及原始对象的差别，让客户端用一致的方式对待合成结构中的对象。

结构：

1.抽象部件（CComponent）:声明合成对象的接口；实现所有类通用接口的缺省行为；声明用于访问和管理其子部件的接口。

2.叶子部件（CLeaf）：表示合成中的叶子节点对象；叶子对象无子节点。用于定义作为基本合成元素的原始对象的行为。

3.合成部件（CComposite）：定义拥有子部件（子节点）的那些部件的行为；提供存储子部件的功能；实现在CComponent接口与子部件有关的操作。

4.客户（CClient）：通过CComponent接口操作合成部件的对象。

。。。。。。

7.Bridge（桥接模式）

Bridge（桥接模式）

     用于将抽象化与实现解耦，使得二者可以独立的变化。

适用情况：

1.为了避免固定的绑定一个属性及其实现，即避免在抽象化角色和实现化角色间建立静态的联系。特别是其实现在运行期需要灵活选择或切换的时候。

2.属性及其实现在派生类中需要扩充，即抽象化角色和实现化角色需要独立的变化。例如：可以对不同的抽象接口和实现部分进行组合，并分别对他们进行独立的扩充。

3.改变一个属性的实现对使用者不产生影响，他的程序也无须重新编译。即实现化角色变化不影响客户端。

结构：

1.抽象化（CAbstraction）:定义抽象化基类的接口。保存并维护对一个实现对象的引用。

2.修正抽象化（CRefinedAbstraction）:扩充抽象化角色，调整和修正基类对抽象化的定义。

3.实现化：（CImplementor）：定义实现基类的接口。这个接口无需一一对应抽象化基类的接口，事实上这两个接口可以完全不同。一般而言实现化角色的接口提供的只是底层的操作，而抽象化角色定义的是依据底层操作所构成的更高一层的操作。

4.具体实现化（CConcreteImplementor）：负责完成实现化积累接口的具体实现。

。。。。。。

6.Adapter（适配器模式、wrapper包装者模式）

Adapter（适配器模式、wrapper包装者模式）

     其作用是将一个接口转换成客户所期待的另外一个接口。从而让多个类共同工作，而这些类原先因为其接口不兼容而无法共同工作。类似一种接口转换装置。接口改变，是我们在编程的时候经常遇到的头疼问题。软件开发在不断的进步，用于实现某一功能的类（或组件）也不会是一成不变的。如果想要给用户提供ige比较稳定的接口，就需要考虑使用适配器来缓冲和协调不同接口的差异，使不同的被适配的类能通过接口转换而实现它的价值。

     适配器模式也体现了依赖反转法则（DIP），即依赖抽象，而不要依赖具体。适配器本身就是一个抽象层的概念。这样用户接口只依赖于抽象的适配器，而不依赖具体的实现类（那些被适配的类）。当具体类（或组件）发生变化时，通过是陪吃重新匹配了变化的API接口，从而使客户程序保持稳定。因为适配器隔离了具体实现类API接口变化所造成的影响。

适用情况：

1.当使用一个现存类（或组件），但你不想要他原来的接口。

2.当你要设计一个可重用的类，需要与其他无关或未知的类合作，也就是这些类不需兼容的接口。

3.你需要使用许多先用的派生类但无法适应所有的接口，而使用一个对象适配器可以转接其基类的接口（只适用于对象的适配器模式）

结构：

1.目标（CTarget）:定义一个客户端使用的特定接口。

2.客户（CClient）:使用目标接口，与和目标接口一致的对象合作。

3.被适配者（CAdaptee）:一个现存需要匹配的接口。

4.适配器（CAdapter）:负责将CAdaptee的接口转换成CTarget的接口。适配器是一个具体的类，这是本模式的核心。

由此可见，但客户端调用Adapter接口时候，Adapter便会调用Adaptee的操作相应请求，该模式就完成了接口的适配过程。

......

5.Prototype（原型模式）

Prototype（原型模式）

     通过给出一个原型对象来指明所要创建对象的类型，然后克隆该原型对象以便创建出更多同类型的新对象。例如：我们的开发IDE，在winform上可以使用copy和paste，呵呵。就这么简单.

适用情况：

1.当需要实例化的类是在运行期指定时。

2.当类实例只是少数不同组合状态之一时，这时候比较好的方式是在适当的状态下使用一些组合的原型并复制他们，而并不是人工的继承这些类。

3.为了避免创建一个与产品类层次平行的工厂类层次时。

结构：

1.抽象原型（CPrototype）:声明一个克隆本身的接口。

2.具体原型（CConcretePrototype）:实现一个克隆本身的操作。

3.客户（CClient）:请求原型克隆其本身以构建新的对象。

。。。

4.Singleton（单例模式）

Singleton（单例模式）

     由于确保一个类在系统中只有一个实例，并负责自行实例化和向整个系统提供对该实例的访问。单例模式的典型应用是建立管理或服务类型的类，并在任何时候都可以为系统提供这样一个公用的全局对象。一个类可以生成多个实例，也可以唯一生成一个实例，前者称为多例，或者称为单例。单例通常用于管理资源，可以避免竞争资源造成的冲突。实际上单例把多例的并行访问资源编程了串行，从而解决了资源竞争的矛盾。单例模式由类本身自行创建这唯一的实例，既能保证在产生实例时检测是否已有该实例产生并提供一个方法访问该实例。如果单例模式的类不是由自身建立，你可以考虑一下将会有什么样的结果？呵呵，这个作为一个思考题目。还有为什么不用全局变量来方位单例对象？

适用情况：

1.一个类只能有一个实例；并且必须提供一个方便的访问途径。

2.这个对象在派生类中必须扩充，则客户对象不需能够直接使用扩充的对象而无需修改其程序代码。

结构：由于就一个类所以，呵呵，免了。

3.Builder（建造者模式）

Builder（建造者模式）

     将一个复杂对象的构造方法从其表现中分离出来，以便同样的构造方法可以建立不同的表现。复杂的对象，是指该复杂对象作为构造的产品通常是由不同部分组成的，而这些部分的不同作用和表现，则构成了该对象的不同表现。

     由于需要创建的对象具有复杂的内部结构，该对象的创建与其个组成部分或相关部分相互依赖，即要生成的产品的属性（部件）相互依赖。所以构建复杂对象不是一蹴而就的，需要按照一定的步骤、算法完成建造过程。如果产品对象的一个属性在另一个属性确定（赋值）之后才有效，或者产品对象的一个部件对象在另一个部件对象确定（创建）之后才有效，此时使用Builder（建造者模式）就可以将建立复杂对象的算法与创建对象及如何进行内部装配分隔开来。由于抽离算法（建造产品的步骤），是稳定的，因此这种模式允许建造的产品有不同的表现。（以上的部分比较绕口，但是请仔细阅读。）

适用情况：

1.建立复杂对象的算法必须与创建对象及如何进行内部装配分离。

2.构建方法必须允许其构建的对象有不同的表现。

结构：

1.建造者（CAbstractBuilder）:定义一个抽象接口以创建产品对想的各个部分。他提供的接口不依赖于所构建产品的不同表现形态，也不依赖于程序的业务逻辑。他按照一定的算法步骤来创建产品的各个部分，例如：BuilderPart1,BuilderPart2,然后进行内部装配（如果需要的话）并返回最终产品，例如：GetProduct.

2.具体建造者（CConcreteBuilder）:实现建造者接口以创建及装配产品的各个部分。分步骤完成建造工作并在完工后提供一个接口来返回该产品的实例。

3.指挥者（CDirector）:使用建造者接口来建造对象。（客户端创建指挥者对象和具体建造者对象，并由指挥者对象指挥具体建造者对象，开始建造产品。）

4.产品（CProduct）:由建造者负责建造的复杂对象。该产品可能有多种复杂的表现形式，但都可以使用建造者统一的建造步骤来建造。

uml图：

暂时略。

模板代码：

暂时略。

2.Abstract Factory（抽象工厂模式、工具箱kit）

Abstract Factory（抽象工厂模式、工具箱kit）

     是所有形态的工厂模式中最为抽象和最具一般性的一种形态，通过抽象工厂提供的接口，客户端不必指定产品的具体类型就能创建多个产品足（product families）中的产品对象。

适用情况：

1.一个系统必须与他的产品类如何构建、组合及表现无关。

2.一个系统必须与各个产品族中的一个族关联。

3.同意产品族的相关产品是共同使用的，这个是重要限制必须在系统设计中体现出来。

4.你提供一个产品类的库，只想让显示他们的接口而不是实现，从而使客户端不依赖于实现。

结构：

1.抽象工厂（CAbstractFactory）:声明构建（生产）抽象工厂产品操作的接口。

2.具体工厂（CConcreteFactory）:实现构建（生产）抽象产品的操作。

3.抽象产品（CAbstractProduct）:声明某一类型对象的接口。

4.具体产品（CConcreteProduct）:相对于某一具体工厂定义欲构建的一个产品对象。并实现抽象产品的接口。

5.客户（CClient）:使用抽象工厂及抽象产品声明的接口，构建并获得最终的产品对象。

     一般的具体工厂类的实例是在运行期被创建的。并由给具体工厂分别创建其负责的具体产品。如果要构建不同的产品对象，这必须使用不同的具体工厂。抽象工厂提供了生产产品的接口，但他并不亲自构建这些产品，而是委托其派生类的具体工厂去创建产品对象。

uml图：

暂时略。呵呵

代码模板：

暂时略。