一、概述在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。 建造者模式可以将一个产品的

一、组合模式简介（Brief Introduction）组合模式，将对象组合成树形结构以表示“部分-整体”的层次结构，组合模式使得用户对单个对象和组合对象的使用具有一致性。 二、解决的问题（What To Solve）解决整合与部分可以被一致对待问题。三、组合模式分析（Analysis）1、组合模式结构Component类：组合中的对

一 意图　　动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。——包装器Wrapper。二 动机　　有时我们希望给某个对象而不是整个类添加一些功能。例如，一个图形用户界面工具箱允许你对任意一个用户界面组件添加一些特性，例如边框，或是一些行为，例如窗口滚动。使用继承机制是添加功能的一种有效途径，从其他类继承过来的边

实际上在软件系统设计和开发中，这种问题也会经常遇到：我们为了完成某项工作购买了一个第三方的库来加快开发。这就带来了一个问题：我们在应用程序中已经设计好了接口，与这个第三方提供的接口不一致，为了使得这些接口不兼容的类（不能在一起工作）可以在一起工作了，Adapter模式提供了将一个类（第三方库）的接口转化为客户（购买使用者）希望的接口。在上面生活中问题的解决方式也就正好对应了Adapter模

一、 桥梁（Bridge）模式桥梁模式是一个非常有用的模式，也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则，包括"开－闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助。理解好这两个原则，有助于形成正确的设计思想和培养良好的设计风格。注：《Java与模式》一书认为Bridge模式不是一个使用频率很高的模式，我不太赞同，我认为Bridge模式中蕴涵了很多设

一. 概述定义：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。换句话说，就是不用重新初始化对象，而是动态地获得对象运行时的状态。再说明白点，就是要一个拷贝过构造函数类似功能的接口。结构图如下： 代码如下：[cpp] //原型类，有一个clone接口  class Prototype { public:

1、关联双向关联：C1-C2：指双方都知道对方的存在，都可以调用对方的公共属性和方法。在GOF的设计模式书上是这样描述的：虽然在分析阶段这种关系是适用的，但我们觉得它对于描述设计模式内的类关系来说显得太抽象了，因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的，更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到，关联一般都是有向的。

UML 2 中的阴和阳在 UML 2 中有二种基本的图范畴：结构图和行为图。每个 UML 图都属于这二个图范畴。结构图的目的是显示建模系统的静态结构。它们包括类，组件和（或）对象图。另一方面，行为图显示系统中的对象的动态行为，包括如对象的方法，协作和活动之类的内容。行为图的实例是活动图，用例图和序列图。大体上的结构图如同我所说的，结构图显示建模系统的静态结构。关注系统的

FlyWeight模式在实现过程中主要是要为共享对象提供一个对象池，其中有一个类似Factory模式的对象构造工厂，当用户需要一个对象的时候，会象工厂发出一个请求对象的消息，工厂会通过对象池遍历池中的对象，如果有直接返回，没有于是创建。1、抽象享元(Flyweight)角色：此角色是所有的具体享元类的基类，为这些类规定出需要实现的公共接口，通过这个接口Flyweight可以接受并作用于