一 单例模式：
定义：
单例模式的意思就是只有一个实例。单例模式确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例。这个类称为单例类。
单例模式的要点有三个：
一是某个类只能有一个实例；
二是它必须自行创建这个实例；
三是它必须自行向整个系统提供这个实例。
举例，在计算机系统中，需要管理的资源包括软件外部资源，譬如每台计算机可以有若干个打印机，但只能有一个Printer Spooler， 以避免两个打印作业同时输出到打印机中。每台计算机可以有若干传真卡，但是只应该有一个软件负责管理传真卡，以避免出现两份传真作业同时传到传真卡中的情况。每台计算机可以有若干通信端口，系统应当集中管理这些通信端口，以避免一个通信端口同时被两个请求同时调用。
二软件工程 组合，关联，聚合的区别
：http://hi.baidu.com/suerodick/item/d996d42f3533390c43634ac2
类间关系
在类图中，除了需要描述单独的类的名称、属性和操作外，我们还需要描述类之间的联系，因为没有类是单独存在的，它们通常需要和别的类协作，创造比单独更大的语义。在类图中，关系用类框之间的连线来表示，连线上和连线端头处的不同修饰符表示不同的关系。类之间的关系有继承（泛化）、关联、聚合和组合。
（1）继承：指的是一个类（称为子类）继承另外的一个类（称为基类）的功能，并增加它自己的新功能的能力，继承是类与类之间最常见的关系。类图中继承的表示是从子类拉出一条闭合的、单键头（或三角形）的实线指向基类。例如，图3.2给出了MFC中 CObject类和菜单类CMenu的继承关系。
图3.2 类的继承
类的继承在C++中呈现为：
class B { }
class A : public B{ }
（2）关联：指的是模型元素之间的一种语义联系，是类之间的一种很弱的联系。关联可以有方向，可以是单向关联，也可以是双向关联。可以给关联加上关联名来描述关联的作用。关联两端的类也可以以某种角色参与关联，角色可以具有多重性，表示可以有多少个参与关联。可以通过关联类进一步描述关联的属性、操作以及其他信息。关联类通过一条虚线与关联连接。对于关联可以加上一些约束，以加强关联的含义。
关联在C++中呈现为：
class A{...}
class B{ ...}
A::Function1(B &b) //或A::Function1(B b) //或A::Function1(B *b)
即一个类作为另一个类方法的参数。
（3）聚合：指的是整体与部分的关系。通常在定义一个整体类后，再去分析这个整体类的组成结构。从而找出一些组成类，该整体类和组成类之间就形成了聚合关系。例如一个航母编队包括海空母舰、驱护舰艇、舰载飞机及核动力攻击潜艇等。需求描述中“包含”、“组成”、“分为…部分”等词常意味着聚合关系。
（4）组合：也表示类之间整体和部分的关系，但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在，部分对象也将不存在。部分对象与整体对象之间具有共生死的关系。
聚合和组合的区别在于：聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。
我们用浅显的例子来说明聚合和组合的区别。“国破家亡”，国灭了，家自然也没有了，“国”和“家”显然也是组合关系。而相反的，计算机和它的外设之间就是聚合关系，因为它们之间的关系相对松散，计算机没了，外设还可以独立存在，还可以接在别的计算机上。在聚合关系中，部分可以独立于聚合而存在，部分的所有权也可以由几个聚合来共享，比如打印机就可以在办公室内被广大同事共用。
在C++语言中，从实现的角度讲，聚合可以表示为：
class A {...}
class B { A* a; .....}
即类B包含类A的指针；
而组合可表示为：
class A{...}
class B{ A a; ...}
即类B包含类A的对象。
准确的UML类图中用空心和实心菱形对聚合和组合进行了区分。
图3.4 聚合和组合
聚合，关联，组合 是对象之间的三种关系。从某种意义上说，继承是一种类的纵向关系，而聚合，关联，组合是对象的横向关系。
其关系强弱为 关联<聚合<组合
关联和聚合的区别主要在语义上，关联的两个对象之间一般是平等的，例如你是我的朋友，聚合则一般不是平等的，例如一个公司包含了很多员工，其实现上是差不多的。聚合和组合的区别则在语义和实现上都有差别，组合的两个对象之间其生命期有很大的关联，被组合的对象是在组合对象创建的同时或者创建之后创建，在组合对象销毁之前销毁。一般来说被组合对象不能脱离组合对象独立存在，而且也只能属于一个组合对象，例如一个文档的版本，必须依赖于文档的存在，也只能属于一个文档。聚合则不一样，被聚合的对象可以属于多个聚合对象，例如一个员工可能可以属于多个公司。
我想举个通俗的例子。
你和你的心脏之间是composition关系(心脏只属于自己)
你和你买的书之间是aggregation关系（书可能是别人的）
你和你的朋友之间是association关系
三桥梁模式
GOF在《设计模式》中给桥梁模式的定义为：将抽象部分与它的实现部分分离，使它们都可以独立地变化。这里的抽象部分和实现部分不是我们通常认为的父类与子类、接口与实现类的关系，而是组合关系。也就是说，实现部分是被抽象部分调用，以用来完成（实现）抽象部分的功能。
在《Thinking in Patterns with Java》一书中，作者将抽象部分叫做“front-end”（权且翻译为“前端”），而实现部分叫做“back-end”（后端）。这种叫法要比抽象实现什么的好理解多了。
桥梁模式由如下四种角色组成：
1) 抽象（Abstraction）角色：它定义了抽象类的接口而且维护着一个指向实现（Implementor）角色的引用。
2) 精确抽象（RefinedAbstraction）角色：实现并扩充由抽象角色定义的接口。
3) 实现（Implementor）角色：给出了实现类的接口，这里的接口与抽象角色中的接口可以不一致。
4) 具体实现（ConcreteImplementor）角色：给出了实现角色定义接口的具体实现。
它再放上个类图就更清晰了：
可是这样的结构能够给我们带来什么呢？？
系统设计中，总是充满了各种变数，这是防不慎防的。比如客户代表可能要求修改某个需求，增加某种功能等等。面对这样那样的变动，你只能去不停的修改设计和代码，并且要开始新的一轮测试……。
那采取什么样的方式可以较好的解决变化带给系统的影响？你可以分析变化的种类，将不变的框架使用抽象类定义出来，然后再将变化的内容使用具体的子类来分别实现。这样面向客户的只是一个抽象类，这种方式可以较好的避免为抽象类中现有接口添加新的实现所带来的影响，缩小了变化带来的影响。但是这可能会造成子类数量的爆炸，并且在某些时候不是很灵活。
但是当你各个子类的行为经常发生变化，或者有一定的重复和组合关系时，我们不妨将这些行为提取出来，也采用接口的方式提供出来，然后以组合的方式将服务提供给原来的子类。这样就达到了前端和被使用的后端独立的变化，而且还达到了后端的重用。
其实这就是桥梁模式的诞生。