thinking in java summary

本书在设计时认真考虑了人们学习 Java 语言的方式。在我授课时，学生们的反映有效地帮助了我认识哪些部分是比较困难的，需特别加以留意。我也曾经一次讲述了太多的问题，但得到的教训是：假如包括了大量新特性，就需要对它们全部作出解释，而这特别容易加深学生们的混淆。因此，我进行了大量努力，使这本书一次尽可能地少涉及一些问题。所以，我在书中的目标是让每一章都讲述一种语言特性，或者只讲述少数几个相互关联的特性。这样一来，读者在转向下一主题时，就能更容易地消化前面学到的知识。下面列出对本书各章的一个简要说明，它们与我实际进行的课堂教学是对应的。
(1) 第1 章：对象入门
这一章是对面向对象的程序设计（OOP）的一个综述，其中包括对“什么是对象”之类的基本问题的回答，并讲述了接口与实现、抽象与封装、消息与函数、继承与合成以及非常重要的多形性的概念。这一章会向大家提出一些对象创建的基本问题，比如构建器、对象存在于何处、创建好后把它们置于什么地方以及魔术般的垃圾收集器（能够清除不再需要的对象）。要介绍的另一些问题还包括通过违例实现的错误控制机制、反应灵敏的用户界面的多线程处理以及连网和因特网等等。大家也会从中了解到是什么使得Java 如此特别，它为什么取得了这么大的成功，以及与面向对象的分析与设计有关的问题。
(2) 第2 章：一切都是对象
本章将大家带到可以着手写自己的第一个 Java 程序的地方，所以必须对一些基本概念作出解释，其中包括对象“句柄”的概念；怎样创建一个对象；对基本数据类型和数组的一个介绍；作用域以及垃圾收集器清除对象的方式；如何将 Java 中的所有东西都归为一种新数据类型（类），以及如何创建自己的类；函数、自变量以及返回值；名字的可见度以及使用来自其他库的组件；static 关键字；注释和嵌入文档等等。
(3) 第3 章：控制程序流程
本章开始介绍起源于C 和C++，由Java 继承的所有运算符。除此以外，还要学习运算符一些不易使人注意的问题，以及涉及造型、升迁以及优先次序的问题。随后要讲述的是基本的流程控制以及选择运算，这些是几乎所有程序设计语言都具有的特性：用if-else 实现选择；用 for 和while 实现循环；用 break 和 continue以及Java 的标签式break 和contiune（它们被认为是Java 中“不见的 gogo”）退出循环；以及用 switch实现另一种形式的选择。尽管这些与C 和C++中见到的有一定的共通性，但多少存在一些区别。除此以外，所有示例都是完整的Java 示例，能使大家很快地熟悉Java 的外观。
(4) 第4 章：初始化和清除
本章开始介绍构建器，它的作用是担保初始化的正确实现。对构建器的定义要涉及函数过载的概念（因为可能同时有几个构建器）。随后要讨论的是清除过程，它并非肯定如想象的那么简单。用完一个对象后，通常可以不必管它，垃圾收集器会自动介入，释放由它占据的内存。这里详细探讨了垃圾收集器以及它的一些特点。在这一章的最后，我们将更贴近地观察初始化过程：自动成员初始化、指定成员初始化、初始化的顺序、static（静态）初始化以及数组初始化等等。
(5) 第5 章：隐藏实现过程
本章要探讨将代码封装到一起的方式，以及在库的其他部分隐藏时，为什么仍有一部分处于暴露状态。首先要讨论的是 package 和 import 关键字，它们的作用是进行文件级的封装（打包）操作，并允许我们构建由类构成的库（类库）。此时也会谈到目录路径和文件名的问题。本章剩下的部分将讨论 public，private 以及protected 三个关键字、“友好”访问的概念以及各种场合下不同访问控制级的意义。
(6) 第6 章：类再生
继承的概念是几乎所有 OOP 语言中都占有重要的地位。它是对现有类加以利用，并为其添加新功能的一种有效途径（同时可以修改它，这是第 7 章的主题）。通过继承来重复使用原有的代码时（再生），一般需要保持“基础类”不变，只是将这儿或那儿的东西串联起来，以达到预期的效果。然而，继承并不是在现有类基础上制造新类的唯一手段。通过“合成”，亦可将一个对象嵌入新类。在这一章中，大家将学习在Java 中重复使用代码的这两种方法，以及具体如何运用。
(7) 第7 章：多形性
若由你自己来干，可能要花9 个月的时间才能发现和理解多形性的问题，这一特性实际是 OOP 一个重要的基础。通过一些小的、简单的例子，读者可知道如何通过继承来创建一系列类型，并通过它们共有的基础类对那个系列中的对象进行操作。通过 Java 的多形性概念，同一系列中的所有对象都具有了共通性。这意味着我们编写的代码不必再依赖特定的类型信息。这使程序更易扩展，包容力也更强。由此，程序的构建和代码的维护可以变得更方便，付出的代价也会更低。此外，Java 还通过“接口”提供了设置再生关系的第三种途径。这儿所谓的“接口”是对对象物理“接口”一种纯粹的抽象。一旦理解了多形性的概念，接口的含义就
很容易解释了。本章也向大家介绍了Java 1.1 的“内部类”。
(8) 第8 章：对象的容纳
对一个非常简单的程序来说，它可能只拥有一个固定数量的对象，而且对象的“生存时间”或者“存在时间”是已知的。但是通常，我们的程序会在不定的时间创建新对象，只有在程序运行时才可了解到它们的详情。此外，除非进入运行期，否则无法知道所需对象的数量，甚至无法得知它们确切的类型。为解决这个常见的程序设计问题，我们需要拥有一种能力，可在任何时间、任何地点创建任何数量的对象。本章的宗旨便是探讨在使用对象的同时用来容纳它们的一些 Java 工具：从简单的数组到复杂的集合（数据结构），如Vector 和 Hashtable 等。最后，我们还会深入讨论新型和改进过的 Java 1.2 集合库。
(9) 第9 章：违例差错控制
Java 最基本的设计宗旨之一便是组织错误的代码不会真的运行起来。编译器会尽可能捕获问题。但某些情况下，除非进入运行期，否则问题是不会被发现的。这些问题要么属于编程错误，要么则是一些自然的出错状况，它们只有在作为程序正常运行的一部分时才会成立。Java 为此提供了“违例控制”机制，用于控制程序运行时产生的一切问题。这一章将解释try、catch、throw、throws 以及finally 等关键字在 Java 中的工作原理。并讲述什么时候应当“掷”出违例，以及在捕获到违例后该采取什么操作。此外，大家还会学习 Java的一些标准违例，如何构建自己的违例，违例发生在构建器中怎么办，以及违例控制器如何定位等等。
(10) 第10 章：Java IO 系统
理论上，我们可将任何程序分割为三部分：输入、处理和输出。这意味着 IO（输入／输出）是所有程序最为关键的部分。在这一章中，大家将学习Java 为此提供的各种类，如何用它们读写文件、内存块以及控制台等。“老”IO 和 Java 1.1 的“新”IO 将得到着重强调。除此之外，本节还要探讨如何获取一个对象、对其进行“流式”加工（使其能置入磁盘或通过网络传送）以及重新构建它等等。这些操作在Java 的1.1 版中都可以自动完成。另外，我们也要讨论Java 1.1 的压缩库，它将用在 Java 的归档文件格式中（JAR）。
(11) 第11 章：运行期类型鉴定
若只有指向基础类的一个句柄，Java 的运行期类型标鉴定（RTTI）使我们能获知一个对象的准确类型是什么。一般情况下，我们需要有意忽略一个对象的准确类型，让 Java 的动态绑定机制（多形性）为那一类型实现正确的行为。但在某些场合下，对于只有一个基础句柄的对象，我们仍然特别有必要了解它的准确类型是什么。拥有这个资料后，通常可以更有效地执行一次特殊情况下的操作。本章将解释 RTTI 的用途、如何使用以及在适当的时候如何放弃它。此外，Java 1.1 的“反射”特性也会在这里得到介绍。
(12) 第12 章：传递和返回对象
由于我们在 Java 中同对象沟通的唯一途径是“句柄”，所以将对象传递到一个函数里以及从那个函数返回一个对象的概念就显得非常有趣了。本章将解释在函数中进出时，什么才是为了管理对象需要了解的。同时也会讲述 String（字串）类的概念，它用一种不同的方式解决了同样的问题。
(13) 第13 章：创建窗口和程序片
Java 配套提供了“抽象 Windows 工具包”（AWT）。这实际是一系列类的集合，能以一种可移植的形式解决视窗操纵问题。这些窗口化程序既可以程序片的形式出现，亦可作为独立的应用程序使用。本章将向大家介绍AWT 以及网上程序片的创建过程。我们也会探讨AWT 的优缺点以及Java 1.1 在GUI 方面的一些改进。同时，重要的“Java Beans”技术也会在这里得到强调。Java Beans 是创建“快速应用开发”（RAD）程序构造工具的重要基础。我们最后介绍的是Java 1.2 的“Swing”库——它使Java 的UI 组件得到了显著的改善。
(14) 第14 章：多线程
Java 提供了一套内建的机制，可提供对多个并发子任务的支持，我们称其为“线程”。这线程均在单一的程序内运行。除非机器安装了多个处理器，否则这就是多个子任务的唯一运行方式。尽管还有别的许多重要用途，但在打算创建一个反应灵敏的用户界面时，多线程的运用显得尤为重要。举个例子来说，在采用了多线程技术后，尽管当时还有别的任务在执行，但用户仍然可以毫无阻碍地按下一个按钮，或者键入一些文字。本章将对Java 的多线程处理机制进行探讨，并介绍相关的语法。
(15) 第15 章 网络编程
开始编写网络应用时，就会发现所有Java 特性和库仿佛早已串联到了一起。本章将探讨如何通过因特网通信，以及Java 用以辅助此类编程的一些类。此外，这里也展示了如何创建一个 Java 程序片，令其同一个“通用网关接口”（CGI）程序通信；揭示了如何用C++编写CGI 程序；也讲述了与 Java 1.1 的“Java 数据库连接”（JDBC）和“远程方法调用”（RMI）有关的问题。
(16) 第16 章 设计范式
本章将讨论非常重要、但同时也是非传统的“范式”程序设计概念。大家会学习设计进展过程的一个例子。首先是最初的方案，然后经历各种程序逻辑，将方案不断改革为更恰当的设计。通过整个过程的学习，大家可体会到使设计思想逐渐变得清晰起来的一种途径。
(17) 第17 章 项目
本章包括了一系列项目，它们要么以本书前面讲述的内容为基础，要么对以前各章进行了一番扩展。这些项目显然是书中最复杂的，它们有效演示了新技术和类库的应用。有些主题似乎不太适合放到本书的核心位置，但我发现有必要在教学时讨论它们，这些主题都放入了本书的附录。
(18) 附录A：使用非Java 代码
对一个完全能够移植的 Java 程序，它肯定存在一些严重的缺陷：速度太慢，而且不能访问与具体平台有关的服务。若事先知道程序要在什么平台上使用，就可考虑将一些操作变成“固有方法”，从而显著加快执行速度。这些“固有方法”实际是一些特殊的函数，以另一种程序设计语言写成（目前仅支持C/C++）。Java 还可通过另一些途径提供对非Java 代码的支持，其中包括 CORBA。本附录将详细介绍这些特性，以便大家能创建一些简单的例子，同非Java 代码打交道。
(19) 附录B：对比 C++和Java
对一个 C++程序员，他应该已经掌握了面向对象程序设计的基本概念，而且Java 语法对他来说无疑是非常眼熟的。这一点是明显的，因为 Java 本身就是从 C++衍生而来。但是，C++和Java 之间的确存在一些显著的差异。这些差异意味着Java 在 C++基础上作出的重大改进。一旦理解了这些差异，就能理解为什么说Java 是一种杰出的语言。这一附录便是为这个目的设立的，它讲述了使Java 与 C++明显有别的一些重要特性。
(20) 附录C：Java 编程规则
本附录提供了大量建议，帮助大家进行低级程序设计和代码编写。
(21) 附录D：性能
通过这个附录的学习，大家可发现自己Java 程序中存在的瓶颈，并可有效地改善执行速度。
(22) 附录E：关于垃圾收集的一些话
这个附录讲述了用于实现垃圾收集的操作和方法。
(23) 附录F：推荐读物
列出我感觉特别有用的一系列 Java 参考书。

第 2 章 一切都是对象
通过本章的学习，大家已接触了足够多的 Java 编程知识，已知道如何自行编写一个简单的程序。此外，对语言的总体情况以及一些基本思想也有了一定程度的认识。然而，本章所有例子的模式都是单线形式的“这样做，再那样做，然后再做另一些事情”。如果想让程序作出一项选择，又该如何设计呢？例如，“假如这样做的结果是红色，就那样做；如果不是，就做另一些事情”。对于这种基本的编程方法，下一章会详细说明在Java 里是如何实现的。

第 3 章 控制程序流程
本章总结了大多数程序设计语言都具有的基本特性：计算、运算符优先顺序、类型转换以及选择和循环等等。现在，我们作好了相应的准备，可继续向面向对象的程序设计领域迈进。在下一章里，我们将讨论对象的初始化与清除问题，再后面则讲述隐藏的基本实现方法。

第四章 初始化和清除
作为初始化的一种具体操作形式，构建器应使大家明确感受到在语言中进行初始化的重要性。与 C++的程序设计一样，判断一个程序效率如何，关键是看是否由于变量的初始化不正确而造成了严重的编程错误（臭虫）。这些形式的错误很难发现，而且类似的问题也适用于不正确的清除或收尾工作。由于构建器使我们能保证正确的初始化和清除（若没有正确的构建器调用，编译器不允许对象创建），所以能获得完全的控制权和安全性。在C++中，与“构建”相反的“破坏”（Destruction）工作也是相当重要的，因为用new 创建的对象必须明确地清除。在Java 中，垃圾收集器会自动为所有对象释放内存，所以 Java 中等价的清除方法并不是经常都需要用到的。
如果不需要类似于构建器的行为，Java 的垃圾收集器可以极大简化编程工作，而且在内存的管理过程中增加更大的安全性。有些垃圾收集器甚至能清除其他资源，比如图形和文件句柄等。然而，垃圾收集器确实也增加了运行期的开销。但这种开销到底造成了多大的影响却是很难看出的，因为到目前为止，Java 解释器的总体运行速度仍然是比较慢的。随着这一情况的改观，我们应该能判断出垃圾收集器的开销是否使Java 不适合做一些特定的工作（其中一个问题是垃圾收集器不可预测的性质）。由于所有对象都肯定能获得正确的构建，所以同这儿讲述的情况相比，构建器实际做的事情还要多得多。特别地，当我们通过“创作”或“继承”生成新类的时候，对构建的保证仍然有效，而且需要一些附加的语法来提供对它的支持。大家将在以后的章节里详细了解创作、继承以及它们对构建器造成的影响。

第五章
对于任何关系，最重要的一点都是规定好所有方面都必须遵守的界限或规则。创建一个库时，相当于建立了同那个库的用户（即“客户程序员”）的一种关系——那些用户属于另外的程序员，可能用我们的库自行构建一个应用程序，或者用我们的库构建一个更大的库。如果不制订规则，客户程序员就可以随心所欲地操作一个类的所有成员，无论我们本来愿不愿意其中的一些成员被直接操作。所有东西都在别人面前都暴露无遗。本章讲述了如何构建类，从而制作出理想的库。首先，我们讲述如何将一组类封装到一个库里。其次，我们讲述类如何控制对自己成员的访问。
一般情况下，一个 C 程序项目会在 50K 到100K 行代码之间的某个地方开始中断。这是由于 C 仅有一个“命名空间”，所以名字会开始互相抵触，从而造成额外的管理开销。而在 Java 中，package 关键字、包命名方案以及import 关键字为我们提供对名字的完全控制，所以命名冲突的问题可以很轻易地得到避免。有两方面的原因要求我们控制对成员的访问。第一个是防止用户接触那些他们不应碰的工具。对于数据类型的内部机制，那些工具是必需的。但它们并不属于用户接口的一部分，用户不必用它来解决自己的特定问题。所以将方法和字段变成“私有”（private）后，可极大方便用户。因为他们能轻易看出哪些对于自己来说是最重要的，以及哪些是自己需要忽略的。这样便简化了用户对一个类的理解。进行访问控制的第二个、也是最重要的一个原因是：允许库设计者改变类的内部工作机制，同时不必担心它会对客户程序员产生什么影响。最开始的时候，可用一种方法构建一个类，后来发现需要重新构建代码，以便达到更快的速度。如接口和实施细节早已进行了明确的分隔与保护，就可以轻松地达到自己的目的，不要求用户改写他们的代码。
利用 Java 中的访问指示符，可有效控制类的创建者。那个类的用户可确切知道哪些是自己能够使用的，哪些则是可以忽略的。但更重要的一点是，它可确保没有任何用户能依赖一个类的基础实施机制的任何部分。作为一个类的创建者，我们可自由修改基础的实施细节，这一改变不会对客户程序员产生任何影响，因为他们不能访问类的那一部分。有能力改变基础的实施细节后，除了能在以后改进自己的设置之外，也同时拥有了“犯错误”的自由。无论当初计划与设计时有多么仔细，仍然有可能出现一些失误。由于知道自己能相当安全地犯下这种错误，所以可以放心大胆地进行更多、更自由的试验。这对自己编程水平的提高是很有帮助的，使整个项目最终能更快、更好地完成。
一个类的公共接口是所有用户都能看见的，所以在进行分析与设计的时候，这是应尽量保证其准确性的最重要的一个部分。但也不必过于紧张，少许的误差仍然是允许的。若最初设计的接口存在少许问题，可考虑添加更多的方法，只要保证不删除客户程序员已在他们的代码里使用的东西。

第六章 类再生
无论继承还是合成，我们都可以在现有类型的基础上创建一个新类型。但在典型情况下，我们通过合成来实现现有类型的“再生”或“重复使用”，将其作为新类型基础实施过程的一部分使用。但如果想实现接口的“再生”，就应使用继承。由于衍生或派生出来的类拥有基础类的接口，所以能够将其“上溯造型”为基础类。对于下一章要讲述的多形性问题，这一点是至关重要的。
尽管继承在面向对象的程序设计中得到了特别的强调，但在实际启动一个设计时，最好还是先考虑采用合成技术。只有在特别必要的时候，才应考虑采用继承技术（下一章还会讲到这个问题）。合成显得更加灵活。但是，通过对自己的成员类型应用一些继承技巧，可在运行期准确改变那些成员对象的类型，由此可改变它们的行为。
尽管对于快速项目开发来说，通过合成和继承实现的代码再生具有很大的帮助作用。但在允许其他程序员完全依赖它之前，一般都希望能重新设计自己的类结构。我们理想的类结构应该是每个类都有自己特定的用途。它们不能过大（如集成的功能太多，则很难实现它的再生），也不能过小（造成不能由自己使用，或者不能增添新功能）。最终实现的类应该能够方便地再生。

第七章 多形性
“多形性”意味着“不同的形式”。在面向对象的程序设计中，我们有相同的外观（基础类的通用接口）以及使用那个外观的不同形式：动态绑定或组织的、不同版本的方法。通过这一章的学习，大家已知道假如不利用数据抽象以及继承技术，就不可能理解、甚至去创建多形性的一个例子。多形性是一种不可独立应用的特性（就象一个switch 语句），只可与其他元素协同使用。我们应将其作为类总体关系的一部分来看待。人们经常混淆 Java 其他的、非面向对象的特性，比如方法过载等，这些特性有时也具有面向对象的某些特征。但不要被愚弄：如果以后没有绑定，就不成其为多形性。
为使用多形性乃至面向对象的技术，特别是在自己的程序中，必须将自己的编程视野扩展到不仅包括单独一个类的成员和消息，也要包括类与类之间的一致性以及它们的关系。尽管这要求学习时付出更多的精力，但却是非常值得的，因为只有这样才可真正有效地加快自己的编程速度、更好地组织代码、更容易做出包容面广的程序以及更易对自己的代码进行维护与扩展。

第八章 对象的容纳
下面复习一下由标准Java（1.0 和1.1）库提供的集合（BitSet 未包括在这里，因为它更象一种负有特殊使命的类）：
(1) 数组包含了对象的数字化索引。它容纳的是一种已知类型的对象，所以在查找一个对象时，不必对结果进行造型处理。数组可以是多维的，而且能够容纳基本数据类型。但是，一旦把它创建好以后，大小便不能变化了。
(2) Vector（矢量）也包含了对象的数字索引——可将数组和 Vector 想象成随机访问集合。当我们加入更多的元素时，Vector 能够自动改变自身的大小。但 Vector 只能容纳对象的句柄，所以它不可包含基本数据类型；而且将一个对象句柄从集合中取出来的时候，必须对结果进行造型处理。
(3) Hashtable（散列表）属于Dictionary（字典）的一种类型，是一种将对象（而不是数字）同其他对象关联到一起的方式。散列表也支持对对象的随机访问，事实上，它的整个设计方案都在突出访问的“高速度”。
(4) Stack（堆栈）是一种“后入先出”（LIFO）的队列。
若你曾经熟悉数据结构，可能会疑惑为何没看到一套更大的集合。从功能的角度出发，你真的需要一套更大的集合吗？对于Hashtable，可将任何东西置入其中，并以非常快的速度检索；对于 Enumeration（枚举），可遍历一个序列，并对其中的每个元素都采取一个特定的操作。那是一种功能足够强劲的工具。但Hashtable 没有“顺序”的概念。Vector 和数组为我们提供了一种线性顺序，但若要把一个元素插入它们任何一个的中部，一般都要付出“惨重”的代价。除此以外，队列、拆散队列、优先级队列以及树都涉及到元素的“排序”——并非仅仅将它们置入，以便以后能按线性顺序查找或移动它们。这些数据结构也非常有用，这也正是标准 C++中包含了它们的原因。考虑到这个原因，只应将标准Java 库的集合看作自己的一个起点。而且倘若必须使用 Java 1.0 或1.1，则可在需要超越它们的时候使用 JGL。如果能使用 Java 1.2，那么只使用新集合即可，它一般能满足我们的所有需要。注意本书在Java 1.1 身上花了大量篇幅，所以书中用到的大量集合都是只能在Java1.1 中用到的那些：Vector 和 Hashtable。就目前来看，这是一个不得以而为之的做法。但是，这样处理亦可提供与老 Java 代码更出色的向后兼容能力。若要用Java1.2 写新代码，新的集合往往能更好地为你服务。

第九章 违例差错控制
通过先进的错误纠正与恢复机制，我们可以有效地增强代码的健壮程度。对我们编写的每个程序来说，错误恢复都属于一个基本的考虑目标。它在Java 中显得尤为重要，因为该语言的一个目标就是创建不同的程序组件，以便其他用户（客户程序员）使用。为构建一套健壮的系统，每个组件都必须非常健壮。在Java 里，违例控制的目的是使用尽可能精简的代码创建大型、可靠的应用程序，同时排除程序里那些不能控制的错误。违例的概念很难掌握。但只有很好地运用它，才可使自己的项目立即获得显著的收益。Java 强迫遵守违例所有方面的问题，所以无论库设计者还是客户程序员，都能够连续一致地使用它。

第十章 运行期类型鉴定RTTI
利用RTTI 可根据一个匿名的基础类句柄调查出类型信息。但正是由于这个原因，新手们极易误用它，因为有些时候多形性方法便足够了。对那些以前习惯程序化编程的人来说，极易将他们的程序组织成一系列switch语句。他们可能用 RTTI 做到这一点，从而在代码开发和维护中损失多形性技术的重要价值。Java 的要求是让我们尽可能地采用多形性，只有在极特别的情况下才使用RTTI。但为了利用多形性，要求我们拥有对基础类定义的控制权，因为有些时候在程序范围之内，可能发现基础类并未包括我们想要的方法。若基础类来自一个库，或者由别的什么东西控制着，RTTI 便是一种很好的解决方案：可继承一个新类型，然后添加自己的额外方法。在代码的其他地方，可以侦测自己的特定类型，并调用那个特殊的方法。这样做不会破坏多形性以及程序的扩展能力，因为新类型的添加不要求查找程序中的switch 语句。但在需要新特性的主体中添加新代码时，就必须用 RTTI 侦测自己特定的类型。
从某个特定类的利益的角度出发，在基础类里加入一个特性后，可能意味着从那个基础类衍生的其他所有类都必须获得一些无意义的“鸡肋”。这使得接口变得含义模糊。若有人从那个基础类继承，且必须覆盖抽象方法，这一现象便会使他们陷入困扰。比如现在用一个类结构来表示乐器（Instrument）。假定我们想清洁管弦乐队中所有适当乐器的通气音栓（Spit Valve），此时的一个办法是在基础类Instrument 中置入一个ClearSpitValve()方法。但这样做会造成一个误区，因为它暗示着打击乐器和电子乐器中也有音栓。针对这种情况，RTTI 提供了一个更合理的解决方案，可将方法置入特定的类中（此时是Wind，即“通气口”）——这样做是可行的。但事实上一种更合理的方案是将 prepareInstrument()置入基础类中。初学者刚开始时往往看不到这一点，一般会认定自己必须使用RTTI。最后，RTTI 有时能解决效率问题。若代码大量运用了多形性，但其中的一个对象在执行效率上很有问题，便可用RTTI 找出那个类型，然后写一段适当的代码，改进其效率。

第十二章 传递和返回对象

第十四章 多线程
何时使用多线程技术，以及何时避免用它，这是我们需要掌握的重要课题。骼它的主要目的是对大量任务进行有序的管理。通过多个任务的混合使用，可以更有效地利用计算机资源，或者对用户来说显得更方便。资源均衡的经典问题是在 IO 等候期间如何利用 CPU。至于用户方面的方便性，最经典的问题就是如何在一个长时间的下载过程中监视并灵敏地反应一个“停止”（stop）按钮的按下。多线程的主要缺点包括：
(1) 等候使用共享资源时造成程序的运行速度变慢。
(2) 对线程进行管理要求的额外CPU 开销。
(3) 复杂程度无意义的加大，比如用独立的线程来更新数组内每个元素的愚蠢主意。
(4) 漫长的等待、浪费精力的资源竞争以及死锁等多线程症状。
线程另一个优点是它们用“轻度”执行切换（100 条指令的顺序）取代了“重度”进程场景切换（1000 条指令）。由于一个进程内的所有线程共享相同的内存空间，所以“轻度”场景切换只改变程序的执行和本地变量。而在“重度”场景切换时，一个进程的改变要求必须完整地交换内存空间。线程处理看来好象进入了一个全新的领域，似乎要求我们学习一种全新的程序设计语言——或者至少学习一系列新的语言概念。由于大多数微机操作系统都提供了对线程的支持，所以程序设计语言或者库里也出现了对线程的扩展。不管在什么情况下，涉及线程的程序设计：
(1) 刚开始会让人摸不着头脑，要求改换我们传统的编程思路；
(2) 其他语言对线程的支持看来是类似的。所以一旦掌握了线程的概念，在其他环境也不会有太大的困难。尽管对线程的支持使Java 语言的复杂程度多少有些增加，但请不要责怪 Java。毕竟，利用线程可以做许多有益的事情。
多个线程可能共享同一个资源（比如一个对象里的内存），这是运用线程时面临的最大的一个麻烦。必须保证多个线程不会同时试图读取和修改那个资源。这要求技巧性地运用 synchronized（同步）关键字。它是一个有用的工具，但必须真正掌握它，因为假若操作不当，极易出现死锁。除此以外，运用线程时还要注意一个非常特殊的问题。由于根据Java 的设计，它允许我们根据需要创建任意数量的线程——至少理论上如此（例如，假设为一项工程方面的有限元素分析创建数以百万的线程，这对Java 来说并非实际）。然而，我们一般都要控制自己创建的线程数量的上限。因为在某些情况下，大量线程会将场面变得一团糟，所以工作都会几乎陷于停顿。临界点并不象对象那样可以达到几千个，而是在100 以下。一般情况下，我们只创建少数几个关键线程，用它们解决某个特定的问题。这时数量的限制问题不大。但在较常规的一些设计中，这一限制确实会使我们感到束手束脚。
大家要注意线程处理中一个不是十分直观的问题。由于采用了线程“调度”机制，所以通过在run()的主循环中插入对 sleep()的调用，一般都可以使自己的程序运行得更快一些。这使它对编程技巧的要求非常高，特别是在更长的延迟似乎反而能提高性能的时候。当然，之所以会出现这种情况，是由于在正在运行的线程准备进入“休眠”状态之前，较短的延迟可能造成“sleep()结束”调度机制的中断。这便强迫调度机制将其中止，并于稍后重新启动，以便它能做完自己的事情，再进入休眠状态。必须多想一想，才能意识到事情真正的麻烦程度。
本章遗漏的一件事情是一个动画例子，这是目前程序片最流行的一种应用。然而，Java JDK 配套提供了解决这个问题的一整套方案（并可播放声音），大家可到java.sun.com 的演示区域下载。此外，我们完全有理由相信未来版本的Java 会提供更好的动画支持——尽管目前的 Web 涌现出了与传统方式完全不同的非 Java、非程序化的许多动画方案。如果想系统学习Java 动画的工作原理，可参考《Core Java——核心Java》一书，由 Corn ell&Horstmann 编著，Prentice -Hall 于 1997 年出版。若欲更深入地了解线程处理，请参考《Concurrent Programming in Java——Java 中的并发编程》，由Doug Lea 编著，Addison-Wiseley 于1997 年出版；或者《Java Threads——Java 线程》，Oaks&Wong 编著，O’Reilly 于1997 年出版。