按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
符的形式）。接下来，创建一个名为Toy 的类，其中包含了一个Battery 数组以及一个toString，用于打印
出所有电池。为Toy 写一个 clone（）方法，令其自动关闭所有 Battery 对象。克隆 Toy 并打印出结果，完成
对它的测试。
（3） 修改CheckCloneable。java，使所有clone（）方法都能捕获CloneNotSupportException 违例，而不是把
它直接传递给调用者。
376
…………………………………………………………Page 378……………………………………………………………
（4） 修改pete。java，为Thing2 和 Thing4 类添加更多的成员对象，看看自己是否能判断计时随复杂性变
化的规律——是一种简单的线性关系，还是看起来更加复杂。
（5） 从Snake。java 开始，创建 Snake 的一个深层复制版本。
377
…………………………………………………………Page 379……………………………………………………………
第十三章 创建窗口和程序片
在Java 1。0 中，图形用户接口（GUI）库最初的设计目标是让程序员构建一个通用的GUI，使其在所有平台
上都能正常显示。
但遗憾的是，这个目标并未达到。事实上，Java 1。0 版的“抽象 Windows 工具包”（AWT ）产生的是在各系
统看来都同样欠佳的图形用户接口。除此之外，它还限制我们只能使用四种字体，并且不能访问操作系统中
现有的高级 GUI 元素。同时，Jave1。0 版的AWT 编程模型也不是面向对象的，极不成熟。这类情况在 Java1。1
版的AWT 事件模型中得到了很好的改进，例如：更加清晰、面向对象的编程、遵循 Java Beans 的范例，以及
一个可轻松创建可视编程环境的编程组件模型。Java1。2 为老的Java 1。0 AWT 添加了 Java 基础类（AWT），
这是一个被称为“Swing”的GUI 的一部分。丰富的、易于使用和理解的Java Beans 能经过拖放操作（像手
工编程一样的好），创建出能使程序员满意的 GUI。软件业的“3 次修订版”规则看来对于程序设计语言也是
成立的（一个产品除非经过第 3 次修订，否则不会尽如人意）。
Java 的主要设计目的之一是建立程序片，也就是建立运行在WEB 浏览器上的小应用程序。由于它们必须是安
全的，所以程序片在运行时必须加以限制。无论怎样，它们都是支持客户端编程的强有力的工具，一个重要
的应用便是在Web 上。
在一个程序片中编程会受到很多的限制，我们一般说它“在沙箱内”，这是由于 Java 运行时一直会有某个东
西——即Java 运行期安全系统——在监视着我们。Jave 1。1 为程序片提供了数字签名，所以可选出能信赖
的程序片去访问主机。不过，我们也能跳出沙箱的限制写出可靠的程序。在这种情况下，我们可访问操作系
统中的其他功能。在这本书中我们自始至终编写的都是可靠的程序，但它们成为了没有图形组件的控制台程
序。AWT 也能用来为可靠的程序建立GUI 接口。
在这一章中我们将先学习使用老的 AWT 工具，我们会与许多支持和使用AWT 的代码程序样本相遇。尽管这有
一些困难，但却是必须的，因为我们必须用老的AWT 来维护和阅读传统的 Java 代码。有时甚至需要我们编写
AWT 代码去支持不能从Java1。0 升级的环境。在本章第二部分，我们将学习Java 1。1 版中新的 AWT 结构并会
看到它的事件模型是如此的优秀（如果能掌握的话，那么在编制新的程序时就可使用这最新的工具。最后，
我们将学习新的能像类库一样加入到Java 1。1 版中的 JFC/Swing 组件，这意味着不需要升级到 Java 1。2 便
能使用这一类库。
大多数的例程都将展示程序片的建立，这并不仅仅是因为这非常的容易，更因为这是 AWT 的主要作用。另
外，当用AWT 创建一个可靠的程序时，我们将看到处理程序的不同之处，以及怎样创建能在命令行和浏览器
中运行的程序。
请注意的是这不是为了描述类的所有程序的综合解释。这一章将带领我们从摘要开始。当我们查找更复杂的
内容时，请确定我们的信息浏览器通过查找类和方法来解决编程中的问题（如果我们正在使用一个开发环
境，信息浏览器也许是内建的；如果我们使用的是 SUN 公司的 JDK 则这时我们要使用 WEB 浏览器并在 Java 根
目录下面开始）。附录F 列出了用于深入学习库知识的其他一些参考资料。
13。1 为何要用 AW T ？
对于本章要学习的“老式”AWT，它最严重的缺点就是它无论在面向对象设计方面，还是在GUI 开发包设计方
面，都有不尽如人意的表现。它使我们回到了程序设计的黑暗年代（换成其他话就是“拙劣的”、“可怕
的”、“恶劣的”等等）。必须为执行每一个事件编写代码，包括在其他环境中利用“资源”即可轻松完成
的一些任务。
许多象这样的问题在Java 1。1 里都得到了缓解或排除，因为：
（1）Java 1。1的新型AWT 是一个更好的编程模型，并向更好的库设计迈出了可喜的一步。而Java Beans 则是
那个库的框架。
（2） “GUI 构建器”（可视编程环境）将适用于所有开发系统。在我们用图形化工具将组件置入窗体的时候，
Java Beans 和新的 AWT 使 GUI 构建器能帮我们自动完成代码。其它组件技术如ActiveX 等也将以相同的形式
支持。
既然如此，为什么还要学习使用老的AWT 呢？原因很简单，因为它的存在是个事实。就目前来说，这个事实
对我们来说显得有些不利，它涉及到面向对象库设计的一个宗旨：一旦我们在库中公布一个组件，就再不能
去掉它。如去掉它，就会损害别人已存在的代码。另外，当我们学习 Java 和所有使用老AWT 的程序时，会发
现有许多原来的代码使用的都是老式AWT 。
378
…………………………………………………………Page 380……………………………………………………………
AWT 必须能与固有操作系统的GUI 组件打交通，这意味着它需要执行一个程序片不可能做到的任务。一个不
被信任的程序片在操作系统中不能作出任何直接调用，否则它会对用户的机器做出不恰当的事情。一个不被
信任的程序片不能访问重要的功能。例如，“在屏幕上画一个窗口”的唯一方法是通过调用拥有特殊接口和
安全检查的标准Java 库。Sun 公司的原始模型创建的信任库将仅仅供给 Web 浏览器中的 Java 系统信任关系
自动授权器使用，自动授权器将控制怎样进入到库中去。
但当我们想增加操作系统中访问新组件的功能时该怎么办？等待Sun 来决定我们的扩展被合并到标准的 Java
库中，但这不一定会解决我们的问题。Java 1。1 版中的新模型是“信任代码”或“签名代码”，因此一个特
殊服务器将校验我们下载的、由规定的开发者使用的公共密钥加密系统的代码。这样我们就可知道代码从何
而来，那真的是Bob 的代码，还是由某人伪装成Bob 的代码。这并不能阻止Bob 犯错误或作某些恶意的事，
但能防止Bob 逃避匿名制造计算机病毒的责任。一个数字签名的程序片—— “被信任的程序片”——在Java
1。1版能进入我们的机器并直接控制它，正像一些其它的应用程序从信任关系自动授权机中得到“信任”并
安装在我们的机器上。
这是老AWT 的所有特点。老的AWT 代码将一直存在，新的 Java 编程者在从旧的书本中学习时将会遇到老的
AWT 代码。同样，老的 AWT 也是值得去学习的，例如在一个只有少量库的例程设计中。老的AWT 所包括的范
围在不考虑深度和枚举每一个程序和类，取而代之的是给了我们一个老AWT 设计的概貌。
13。2 基本程序片
库通常按照它们的功能来进行组合。一些库，例如