按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
if（t instanceof Aluminum）
alBin。addElement（t）；
if（t instanceof Paper）
paperBin。addElement（t）；
if（t instanceof Glass）
glassBin。addElement（t）；
｝
Trash。sumValue（alBin）；
Trash。sumValue（paperBin）；
Trash。sumValue（glassBin）；
Trash。sumValue（bin）；
｝
｝ ///：~
所有Trash 对象——以及ParseTrash 及支撑类——现在都成为名为c16。trash 的一个包的一部分，所以它们
可以简单地导入。
无论打开包含了 Trash 描述信息的数据文件，还是对那个文件进行解析，所有涉及到的操作均已封装到
603
…………………………………………………………Page 605……………………………………………………………
static （静态）方法ParseTrash。fillBin（）里。所以它现在已经不是我们设计过程中要注意的一个重点。在
本章剩余的部分，大家经常都会看到无论添加的是什么类型的新类，ParseTrash。fillBin（）都会持续工作，
不会发生改变，这无疑是一种优良的设计方案。
提到对象的创建，这一方案确实已将新类型加入系统所需的变动严格地“本地化”了。但在使用 RTTI 的过程
中，却存在着一个严重的问题，这里已明确地显露出来。程序表面上工作得很好，但却永远侦测到不能“硬
纸板”（Cardboard）这种新的废品类型——即使列表里确实有一个硬纸板类型！之所以会出现这种情况，完
全是由于使用了RTTI 的缘故。RTTI 只会查找那些我们告诉它查找的东西。RTTI 在这里错误的用法是“系统
中的每种类型”都进行了测试，而不是仅测试一种类型或者一个类型子集。正如大家以后会看到的那样，在
测试每一种类型时可换用其他方式来运用多形性特征。但假如以这种形式过多地使用 RTTI，而且又在自己的
系统里添加了一种新类型，很容易就会忘记在程序里作出适当的改动，从而埋下以后难以发现的 Bug。因
此，在这种情况下避免使用RTTI 是很有必要的，这并不仅仅是为了表面好看——也是为了产生更易维护的代
码。
16。5 抽象的应用
走到这一步，接下来该考虑一下设计方案剩下的部分了——在哪里使用类？既然归类到垃圾箱的办法非常不
雅且过于暴露，为什么不隔离那个过程，把它隐藏到一个类里呢？这就是著名的“如果必须做不雅的事情，
至少应将其本地化到一个类里”规则。看起来就象下面这样：
现在，只要一种新类型的Trash 加入方法，对TrashSorter 对象的初始化就必须变动。可以想象，
TrashSorter 类看起来应该象下面这个样子：
class TrashSorter extends Vector ｛
void sort（Trash t） ｛ /* 。。。 */ ｝
｝
也就是说，TrashSorter 是由一系列句柄构成的 Vector （系列），而那些句柄指向的又是由Trash 句柄构成
的Vector；利用 addElement（），可以安装新的TrashSorter，如下所示：
TrashSorter ts = new TrashSorter（）；
ts。addElement（new Vector（））；
但是现在，sort（）却成为一个问题。用静态方式编码的方法如何应付一种新类型加入的事实呢？为解决这个
问题，必须从sort（）里将类型信息删除，使其需要做的所有事情就是调用一个通用方法，用它照料涉及类型
处理的所有细节。这当然是对一个动态绑定方法进行描述的另一种方式。所以sort（）会在序列中简单地遍
历，并为每个Vector 都调用一个动态绑定方法。由于这个方法的任务是收集它感兴趣的垃圾片，所以称之为
grab（Trash）。结构现在变成了下面这样：
604
…………………………………………………………Page 606……………………………………………………………
其中，TrashSorter 需要调用每个 grab（）方法；然后根据当前Vector 容纳的是什么类型，会获得一个不同的
结果。也就是说，Vector 必须留意自己容纳的类型。解决这个问题的传统方法是创建一个基础“Trash
bin”（垃圾筒）类，并为希望容纳的每个不同的类型都继承一个新的衍生类。若Java 有一个参数化的类型
机制，那就也许是最直接的方法。但对于这种机制应该为我们构建的各个类，我们不应该进行麻烦的手工编
码，以后的“观察”方式提供了一种更好的编码方式。
OOP 设计一条基本的准则是“为状态的变化使用数据成员，为行为的变化使用多性形”。对于容纳Paper （纸
张）的Vector，以及容纳 Glass （玻璃）的Vector，大家最开始或许会认为分别用于它们的 grab（）方法肯定
会产生不同的行为。但具体如何却完全取决于类型，而不是其他什么东西。可将其解释成一种不同的状态，
而且由于Java 有一个类可表示类型（Class），所以可用它判断特定的Tbin 要容纳什么类型的 Trash。
用于Tbin 的构建器要求我们为其传递自己选择的一个Class。这样做可告诉Vector 它希望容纳的是什么类
型。随后，grab（）方法用 Class BinType 和 RTTI 来检查我们传递给它的 Trash 对象是否与它希望收集的类型
相符。
下面列出完整的解决方案。设定为注释的编号（如*1*）便于大家对照程序后面列出的说明。
//： RecycleB。java
// Adding more objects to the recycling problem
package c16。recycleb；
import c16。trash。*；
import java。util。*；
// A vector that admits only the right type：
class Tbin extends Vector ｛
Class binType；
Tbin（Class binType） ｛
this。binType = binType；
｝
boolean grab（Trash t） ｛
// paring class types：
if（t。getClass（）。equals（binType）） ｛
addElement（t）；
return true； // Object grabbed
｝
return false； // Object not grabbed
｝
｝
class TbinList extends Vector ｛ //（*1*）
boolean sort（Trash t） ｛
Enumeration e = elements（）；
605
…………………………………………………………Page 607……………………………………………………………
while（e。hasMoreElements（）） ｛
Tbin bin = （Tbin）e。nextElement（）；
if（bin。grab（t）） return true；
｝
return false； // bin not found for t
｝
void sortBin（Tbin bin） ｛ // （*2*）
Enumeration e = bin。elements（）；
while（e。hasMoreElements（））
if（！sort（（Trash）e。nextElement（）））
System。out。println（〃Bin not found〃）；
｝
｝
public class RecycleB ｛
static Tbin bin = new Tbin （Trash。class）；
public static void main（String＇＇ args） ｛
// Fill up the Trash bin：
ParseTrash。fillBin（〃Trash。dat〃； bin）；
TbinList trashBins = new TbinList（）；
trashBins。addElement（
new Tbin（Aluminum。class））；
trashBins。addElement（
new Tbin（Paper。class））；
trashBins。addElement（
new Tbin（Glass。class））；
// add one line here： （*3*）