按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
WeightVisitor wv = new WeightVisitor（）；
Enumeration it = bin。elements（）；
while（it。hasMoreElements（）） ｛
Visitable v = （Visitable）it。nextElement（）；
v。accept（pv）；
v。accept（wv）；
｝
pv。total（）；
wv。total（）；
｝
｝ ///：~
注意main（）的形状已再次发生了变化。现在只有一个垃圾（Trash）筒。两个Visitor 对象被接收到序列中
的每个元素内，它们会完成自己份内的工作。Visitor 跟踪它们自己的内部数据，计算出总重和价格。
最好，将东西从序列中取出的时候，除了不可避免地向Trash 造型以外，再没有运行期的类型验证。若在
Java 里实现了参数化类型，甚至那个造型操作也可以避免。
对比之前介绍过的双重派遣方案，区分这两种方案的一个办法是：在双重派遣方案中，每个子类创建时只会
过载其中的一个过载方法，即 add（）。而在这里，每个过载的visit（）方法都必须在 Visitor 的每个子类中进
行过载。
1。 更多的结合？
这里还有其他许多代码，Trash 结构和 Visitor 结构之间存在着明显的“结合”（Coupling ）关系。然而，
在它们所代表的类集内部，也存在着高度的凝聚力：都只做一件事情（Trash 描述垃圾或废品，而Visitor
描述对垃圾采取什么行动）。作为一套优秀的设计方案，这无疑是个良好的开端。当然就目前的情况来说，
只有在我们添加新的Visitor 类型时才能体会到它的好处。但在添加新类型的Trash 时，它却显得有些碍手
碍脚。
类与类之间低度的结合与类内高度的凝聚无疑是一个重要的设计目标。但只要稍不留神，就可能妨碍我们得
到一个本该更出色的设计。从表面看，有些类不可避免地相互间存在着一些“亲密”关系。这种关系通常是
成对发生的，可以叫作“对联”（Couplet）——比如集合和继承器（Enumeration）。前面的Trash
Visitor 对似乎也是这样的一种“对联”。
16。8 RTTI 真的有害吗
本章的各种设计方案都在努力避免使用RTTI，这或许会给大家留下“RTTI 有害”的印象（还记得可怜的
goto 吗，由于给人印象不佳，根本就没有放到Java 里来）。但实际情况并非绝对如此。正确地说，应该是
RTTI 使用不当才“有害”。我们之所以想避免 RTTI 的使用，是由于它的错误运用会造成扩展性受到损害。
而我们事前提出的目标就是能向系统自由加入新类型，同时保证对周围的代码造成尽可能小的影响。由于
RTTI 常被滥用（让它查找系统中的每一种类型），会造成代码的扩展能力大打折扣——添加一种新类型时，
必须找出使用了RTTI 的所有代码。即使仅遗漏了其中的一个，也不能从编译器那里得到任何帮助。
然而，RTTI 本身并不会自动产生非扩展性的代码。让我们再来看一看前面提到的垃圾回收例子。这一次准备
引入一种新工具，我把它叫作TypeMap。其中包含了一个Hashtable （散列表），其中容纳了多个Vector，
但接口非常简单：可以添加（add（））一个新对象，可以获得（get（））一个Vector，其中包含了属于某种特
定类型的所有对象。对于这个包含的散列表，它的关键在于对应的Vector 里的类型。这种设计方案的优点
（根据Larry O'Brien 的建议）是在遇到一种新类型的时候，TypeMap 会动态加入一种新类型。所以不管什
么时候，只要将一种新类型加入系统（即使在运行期间添加），它也会正确无误地得以接受。
我们的例子同样建立在 c16。Trash 这个“包”（Package）内的Trash 类型结构的基础上（而且那儿使用的
Trash。dat 文件可以照搬到这里来）。
//： DynaTrash。java
// Using a Hashtable of Vectors and RTTI
// to automatically sort trash into
// vectors。 This solution； desp ite the
618
…………………………………………………………Page 620……………………………………………………………
// use of RTTI； is extensible。
package c16。dynatrash；
import c16。trash。*；
import java。util。*；
// Generic TypeMap works in any situation：
class TypeMap ｛
private Hashtable t = new Hashtable（）；
public void add（Object o） ｛
Class type = o。getClass（）；
if（t。containsKey（type））
（（Vector）t。get（type））。addElement（o）；
else ｛
Vector v = new Vector（）；
v。addElement（o）；
t。put（type；v）；
｝
｝
public Vector get（Class type） ｛
return （Vector）t。get（type）；
｝
public Enumeration keys（） ｛ return t。keys（）； ｝
// Returns handle to adapter class to allow
// callbacks from ParseTrash。fillBin（）：
public Fillable filler（） ｛
// Anonymous inner class：
return new Fillable（） ｛
public void addTrash（Trash t） ｛ add（t）； ｝
｝；
｝
｝
public class DynaTrash ｛
public static void main（String＇＇ args） ｛
TypeMap bin = new TypeMap（）；
ParseTrash。fillBin（〃Trash。dat〃；bin。filler（））；
Enumeration keys = bin。keys（）；
while（keys。hasMoreElements（））
Trash。sumValue（
bin。get（（Class）keys。nextElement（）））；
｝
｝ ///：~
尽管功能很强，但对TypeMap 的定义是非常简单的。它只是包含了一个散列表，同时add（）负担了大部分的
工作。添加一个新类型时，那种类型的Class 对象的句柄会被提取出来。随后，利用这个句柄判断容纳了那
类对象的一个Vector 是否已存在于散列表中。如答案是肯定的，就提取出那个 Vector，并将对象加入其
中；反之，就将Class 对象及新Vector 作为一个“键－值”对加入。
利用keys（） ，可以得到对所有Class 对象的一个“枚举”（Enumeration），而且可用get（），可通过Class
对象获取对应的Vector。
filler（）方法非常有趣，因为它利用了 ParseTrash。fillBin（）的设计——不仅能尝试填充一个Vector，也能
用它的 addTrash（）方法试着填充实现了 Fillable （可填充）接口的任何东西。filter（） 需要做的全部事情就
是将一个句柄返回给实现了Fillable 的一个接口，然后将这个句柄作为参数传递给 fillBin（），就象下面这
619
…………………………………………………………Page 621……………………………………………………………
样：
ParseTrash。fillBin（〃Trash。dat〃； bin。filler（））；
为产生这个句柄，我们采用了一个“匿名内部类”（已在第7 章讲述）。由于根本不需要用一个已命名的类
来实现Fillable ，只需要属于那个类的一个对象的句柄即可，所以这里使用匿名内部类是非常恰当的。
对这个设计，要注意的一个地方是尽管没有设计成对归类加以控制，但在 fillBin（）每次进行归类的时候，
都会将一个 Trash 对象插入 bin。
通过前面那些例子的学习，DynaTrash 类的大多数部分都应当非常熟悉了。这一次，我们不再将新的 Trash
对象置入类型Vector 的一个bin 内。由于bin 的类型为TypeMap，所以将垃圾（Trash）丢进垃圾筒（Bin）
的时候，TypeMap 的内部归类机制会立即进行适当的分类。在TypeMap 里遍历并对每个独立的 Vector 进行操
作，这是一件相当简单的事情：
Enumeration keys = bin。keys（）；
while（keys。hasMoreElements（））
Trash。sumValue（
bin。get（（Class）keys。nextElement（）））；
就象大家看到的那样，新类型向系统的加入根本不会影响到这些代码，亦不会影响TypeMap 中的代码。这显
然是解决问题最圆满的方案。尽管它确实严重依赖 RTTI，但请注意散列表中的每个键－值对都只查找一种类
型。除此以外，在我们增加一种新类型的时候，不会陷入“忘记”向系统加入正确代码的尴尬境地，因为根
本就没有什么代码需要添加。
16。9 总结
从表面看，由于象 TrashVisitor。java 这样的设计包含了比早期设计数量更多的代码，所以会留下效率不高
的印象。试图用各种设计方案达到什么目的应该是我们考虑的重点。设计范式特别适合“将发生变化的东西
与保持不变的东西隔离开”。而“发生变化的东西”可以代表许多种变化。之所以发生变化，可能是由于程
序进入一个新环境，或者由于当前环境的一些东西发生了变化（例如“用户希望在屏幕上当前显示的图示中
添加一种新的几何形状”）。或者就象本章描述的那样，变化可能是对代码主体的不断改进。尽管废品分类
以前的例子强调了新型Trash 向系统的加入，但TrashVisitor。java 允许我们方便地添加新功能，同时不会
对Trash 结构造成干扰。TrashVisitor。java 里确实多出了许多代码，但在 Visitor 里添加新功能只需要极
小的代价。如果经常都要进行此类活动，那么多一些代码也是值得的。
变化序列的发现并非一件平常事；在程序的初始设计出台以前，那些分析家一般不可能预测到这种变化。除
非进入项目设计的后期，否则一些必要的信息是不会显露出来的：有时只有进入设计或最终实现阶段，才能
体会到对自己系统一个更深入或更不易察觉需要。添加新类型时（这是“回收”例子最主要的一个重点），
可能会意识到只有自己进入维护阶段，而且开始扩充系统时，才需要一个特定的继承结构。
通过设计范式的学习，大家可体会到最重要的一件事情就是本书一直宣扬的一个观点——多形性是OOP （面
向对象程序设计）的全部——已发生了彻底的改变。换句话说，很难“获得”多形性；而一旦获得，就需要
尝试将自己的所有设计都造型到一个特定的模子里去。
设计范式要表明的观点是“OOP 并不仅仅同多形性有关”。应当与 OOP 有关的是“将发生变化的东西同保