Bridge模式
UML图：
解决的问题：bridge模式完成了抽象和实现部分的分离。两边变化互相不影响，提高了模块的内聚性。
原理：利用多态性，Abstraction类中包含AbstractionImp类的引用。
Adapter模式：
UML图
解决的问题：开发过程中有时会使用第三方库，但本身程序的接口已经设计好，且和第三方库是不兼容的。 此时可以利用适配器模式，从本身程序继承接口，并代理到第三方程序具体实现
原理： Adapter继承自接口Target类，并且Adapter中包含Adptee的指针对象。target的request()实际由Adaptee的SpecificRequest（）实现。
注意：接口类（target）与第三方类（Adptee）具有不同的接口名称（request()和SpecificRequest（））
Decorator模式：
UML图
解决的问题：开发中通常会发生要给已知的类天剑新功能，一般的做法是我们直接在原类的基础上派生子类，这种方式可能导致类的深度过大，导致程序的可读性降低。而装饰器模式可以很好的解决这个问题，我们不需要在为类一层一层的派生子类，而是通过实现不同的ConcreteDecorator子类来完成新功能的添加。
原理：ConcreteComponent（待装饰的类）和Decorator（装饰父类）都继承自component类并拥有同样的基准Operation(),Decorator类中包含有component对象的指针（指向ConcreteComponent）。 而ConcreteDecoratorlei类中的operation会首先调用基准对象的operation（），然后可以添加新的功能AddBehavior（）.
Composite模式
UML图
解决的问题： Composite模式很好地解决了将一个对象完成树状（或其他数据结构）形式的构建。
原理：Composite和Leaf均派生自接口Component， 在Composite类中完成Leaf对象的结构组织（例如树状，vector，list），Composite的operation类调用Leaf对象的operation完成具体对象的操作。
FlyWeight 模式
UML图
解决的问题：当程序要创建大量具有相同特征的“小对象”时，会造成内存的浪费。享元模式就是为了解决这个问题，在FlyWeight中包含有对象的缓存池，根据需要给client提供共享对象。
Facade模式
UML图
解决的问题：在开发中某一接口的实现可能分散在不同的类中，而该接口的使用者实际不需要了解实现的细节子类，此时可以通过Facade模式屏蔽具体的实现。
原理： Facade类中定义OperationWrapper方法，并包含具体实现类SubSystem1和SubSystem2的指针对象。在OperationWrapper()中调用Subsystem1和Subsystem2中的Operation（）具体实现操作，从而屏蔽具体对象SubSystem1和SubSystem2.
Proxy模式
UML图
解决的问题：解决某些性能或者权限控制等问题时，可以将具体操作交给代理完成。（需进一步理解！！！）