代理(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 工厂实际上是一个对象池,隐式的具备管理器的特点。