代理（Proxy）模式：
如果业务类没有安全机制，什么操作都可以做，什么危险都可能发生。代理模式提供了一种解决危机的办法。派生一些业务的兄弟类作为业务类的代理，这样，老板有老板的代理类，营销有营销的代理类。永远不直接使用那个深藏杀机的业务类。
问题解决。图形如下：
图中，代理类邀请业务类做具体操作。
面具（Adapter）模式：
字面的翻译是适配器，我认为翻译成面具好理解一点。
如果你手里有一个做好的东西：足球类，没有源码，但可以引用进来。现在你发现，其实这个足球类和你程序中的球类是继承关系，和你程序中篮球什么的是兄弟。因为足球不是你写的，无法要求足球重新派生于你的球类。经过辗转反侧，聪明的你从面具找到了灵感。
如上图，Adapter 叫做足球面具，Adaptee 是折磨你的足球。足球面具自己没什么方法，它的方法都来自足球的类方法。它的强项是出身好，这个面具类从你的球类派生，确保了以后可以运用多态。
桥合（Bridge）模式：
只要你用接口，就是用桥合模式。这个模式可能在成书的时候没有语言级别的实现，现在时代不同了，凡是 IXxxx，就是桥合。在 .net 里接口很常见，没有必要举例证明了。
组合（composite）模式：
考虑文件夹、文件，在做抽象的时候，我们把它们放在一起，作为兄弟，然后为它们构造一个父类，叫做文件项目。文件项目类派生的文件夹里，可以又可以放文件夹和文件，也就是说，文件夹是文件文件项目的容器。
解决树状的组织问题，常用到这种模式。
注意上图的 Composite 类，可以容纳它的基类 Component。
装饰（decorator）模式：
在使用流的时候可能已经发现这个问题。基本的流有文本流，二进制流。现在，需要一个缓冲机制，于是：
X) 发明可缓冲文本流，可缓冲二进制流
这种做法是危险的，举个例子，进一步要求加密，那么你就要发明：可加密可缓冲文本流，可加密不可缓冲文本流，不可加密可缓冲……（以下省略 200 字）。
.net 里是这么做的，缓冲流和加密流均从流派生，可以视为流。它们的构造函数都要求提供一个流，作为它们的配件。缓冲流和加密流在邀请配件执行动作的时候，做出相应的调校行为，补充缓冲和加密的功能。
java 里也类似， .net 抄了很多 java 的东西。
这个方法很酷，用过的人都有印象，会自觉的模仿。难怪 java 怎么做的 .net 也跟着怎么做。
上图的菱形表示子类需要一个基类作为配件。
事务（Facade）模式：
根据目前的应用来看，这个模式在事务里用的最多——不妨以偏概全，称之为事务。事务的概念是，把一些粒度很小的动作合并为一个事务，一次处理。引入事务还有原子性的考虑，可以回滚加锁。
事务模式和回滚没多大关系，它只是将分散在各个对象里的方法合并起来完成一个功能。这样，小对象也可以不发布给外界，只发布这个事务类就可以了。所以，这个事务类是小对象们的门面，facade 直接翻译是门面的意思。
调色板（flyweight）模式：
被翻译成享元。反对。
做过位图的人知道，有一种 256 色图片。最多只有 256 种颜色。选好颜色以后，例如红色是 1 号，在图片里要表示红色就不写 0xff0000，只写 1 就可以了。这是调色板的含义。
在 Word 里，用户选择的效果虽然花样多，仍然可以归纳为那么几种，把它们放在一个集合里。假如那个花，是粗斜体，编号为 1。以后所有的粗斜样式都可以记录为 <1>花</1>，而不必记录为<粗体><斜体>花</斜体></粗体>。
学过 css 的人都知道这样做的好处。
注意 FlyWeight 工厂的行为：如果不存在请求的 key，就创建一个，如果存在，就沿用以前的。所以，flyweight 工厂实际上是一个对象池，隐式的具备管理器的特点。
