第五章隐藏具体实现.doc

第五章 隐藏具体实现 在面向对象设计中，要考虑的一个基本问题是“如何将变动的事物与保持不变的事物相互隔 离”。这对程序库（library）而言尤为重要。该程序库的使用者（客户端程序员，client programmer）必须能够信赖他所使用的那部分程序库，并且能够知道如果程序库出现了 新版本，他们并不需要改写代码。从另一个方面来说，程序库的开发者必须有权限进行修改 和改进，并确保客户代码不会因为这些改动而受到影响。 这一目标可以通过达成协定来加以实现。例如，程序库开发者必须同意在改动程序库中的 class时不得删除任何现有方法，因为那样会破坏客户端程序员的代码。但是，与之相反的 情况会更加棘手。在有域存在的情况下，程序库开发者要怎样才能知道究竟都有哪些域已经 被客户端程序员所调用了呢？这对于方法仅为类的实现的一部分，因此并不想让客户端程序 员直接使用的情况来说同样如此。但如果程序开发者想要移除旧的实现而要添加新的实现 时，结果将会怎样呢？改动任何一个成员都有可能破坏客户端程序员的代码。于是程序库开 发者会手脚被缚，无法对任何事物进行改动。 为了解决这一问题，Java提供了访问权限修饰词(access specifier)供程序库开发人员来 向客户端程序员指明哪些是可用的，哪些是不可用的。访问权限控制的等级，从最大权限到 最小权限依次为：public, protected，包访问权限 (没有关键词),和 private。根据前述内容，你可能会认为，作为一名程序库设计员，你会尽可能将一切方法都定为private，而仅向客户端程序员公开你愿意让他们使用的方法。这样做是完全正确的，但是对于那些经 常使用别的语言（特别是c语言）编写程序并在访问事物时不受任何限制的人而言，却是与 他们的直觉相违背的。到了本章末，你将会信服 Java的访问权限控制的价值。 不过，构件程序库（component library）的概念以及对于谁有权取用该程序库构件的控制都还是不完善的。其中仍旧存在着如何将构件捆绑到一个内聚的程序库单元中的问题。对于这一点，Java用关键字 package加以控制，而访问权限会因类是存在于一个相同的包，还是存在于一个单独的包而受到影响。为此，要开始学习本章，你首先要学习如何将程序库构件置于包中，然后你就会理解访问权限修饰词的全部含义。 包（package）:程序库单元 当你使用关键字 import来导入整个程序库时，如： import java.util.*; 这个包就变为可用的了。这将把作为标准Java一部分发布的整个 utility程序库都引入 到程序中来。例如，java.util中有一个叫作 ArrayList的类，你现在既可以用全称 java.util.ArrayList来指定（这样你就不必使用 import语句了），也可以仅指定为 ArrayList（缘于 import）。 如果你想引入一个单一的类，你可以在 import语句中命名该类 import java.util.ArrayList; 现在，你就可以不受任何限定而直接使用ArrayList了。但是，这样做 java.util中的其 他类就都变为是不可用的了。 我们之所以要导入，就是要提供一个管理名字空间（name spaces）的机制。所有类成员 的名称都是彼此隔离的。A类中的方法 f( )与 B类中具有相同参数列表(argument list) 的方法 f( )不会彼此冲突。但是如果类名称相互冲突又该怎么办呢？假设你编写了一个 Stack类并安装到了一台机器上，而该机器上已经有了一个别人编写的Stack类，我们该 如何解决？名字之间的潜在冲突使得在 java中对名称空间进行完全控制，并能够不受 Internet的限制创建唯一的名字就成为了非常重要的事情。 到目前为止，书中大多数示例都存于单一文件之中，并专为本机使用（local use）而设计 ,因而尚未受到包名（package name）的干扰。（此时类名称被放于“缺省包”中）这当然 也是一种选择，而且出于简易性的考虑，在本书其它任何部分都尽可能地使用了此方法。不 过如果你正在准备编写能够与其他 java程序在同一台机器上共存的 java程序的话，你就 需要考虑如何防止类名称之间的冲突。 如果你编写一个 java源代码文件，此文件通常被称为编译单元（compilation unit)(有时 也被称为转译单元（translation unit）)。每个编译单元都必须有一个后缀名 .java，而在编译单元之中则可以有一个 public类，该类的名称必须于文件的名称相同（包括大小写， 但不包括文件的后缀名.java）。每个编译单元只能有一个 public类，否则编译器就不会 接受。如果在该编译单