《Java编程思想第4版[中文版](PDF格式)》第289章

的继承，并用super　关键字指出准备在基础类中调用的方法，它与我们当前所在的方法具有相同的名字（然　
而，Java　中的super　关键字只允许我们访问父类的方法——亦即分级结构的上一级）。通过在　C＋＋中设定基　
础类的作用域，我们可访问位于分级结构较深处的方法。亦可用　super　关键字调用基础类构建器。正如早先　
指出的那样，所有类最终都会从Object　里自动继承。和C＋＋不同，不存在明确的构建器初始化列表。但编译　
器会强迫我们在构建器主体的开头进行全部的基础类初始化，而且不允许我们在主体的后面部分进行这一工　
作。通过组合运用自动初始化以及来自未初始化对象句柄的异常，成员的初始化可得到有效的保证。
public　class　Foo　extends　Bar　｛
public　Foo（String　msg）　｛
super（msg）；　//　Calls　base　constructor
｝
public　baz（int　i）　｛　//　Override
super。baz（i）；　//　Calls　base　method
｝
｝
（32）　Java　中的继承不会改变基础类成员的保护级别。我们不能在Java　中指定public，private　或者　
protected　继承，这一点与C＋＋是相同的。此外，在衍生类中的优先方法不能减少对基础类方法的访问。例　
如，假设一个成员在基础类中属于　public，而我们用另一个方法代替了它，那么用于替换的方法也必须属于　
public　（编译器会自动检查）。
（33）　Java提供了一个　interface　关键字，它的作用是创建抽象基础类的一个等价物。在其中填充抽象方　
法，且没有数据成员。这样一来，对于仅仅设计成一个接口的东西，以及对于用　extends　关键字在现有功能　
基础上的扩展，两者之间便产生了一个明显的差异。不值得用　abstract　关键字产生一种类似的效果，因为我　
们不能创建属于那个类的一个对象。一个　abstract　（抽象）类可包含抽象方法（尽管并不要求在它里面包含　
什么东西），但它也能包含用于具体实现的代码。因此，它被限制成一个单一的继承。通过与接口联合使　
用，这一方案避免了对类似于　C＋＋虚拟基础类那样的一些机制的需要。
为创建可进行“例示”（即创建一个实例）的一个　interface　（接口）的版本，需使用implements　关键字。　
它的语法类似于继承的语法，如下所示：
674　
…………………………………………………………Page　676……………………………………………………………
public　interface　Face　｛
public　void　smile（）；
｝
public　class　Baz　extends　Bar　implements　Face　｛
public　void　smile（　）　｛
System。out。println（〃a　warm　smile〃）；
｝
｝
（34）　Java　中没有virtual　关键字，因为所有非static　方法都肯定会用到动态绑定。在Java　中，程序员不　
必自行决定是否使用动态绑定。C＋＋之所以采用了　virtual，是由于我们对性能进行调整的时候，可通过将其　
省略，从而获得执行效率的少量提升（或者换句话说：“如果不用，就没必要为它付出代价”）。virtual　
经常会造成一定程度的混淆，而且获得令人不快的结果。final　关键字为性能的调整规定了一些范围——它　
向编译器指出这种方法不能被取代，所以它的范围可能被静态约束（而且成为嵌入状态，所以使用C＋＋非　
virtual　调用的等价方式）。这些优化工作是由编译器完成的。
（35）　Java不提供多重继承机制（MI），至少不象C＋＋那样做。与　protected　类似，MI　表面上是一个很不错　
的主意，但只有真正面对一个特定的设计问题时，才知道自己需要它。由于Java　使用的是“单根”分级结　
构，所以只有在极少的场合才需要用到MI。interface　关键字会帮助我们自动完成多个接口的合并工作。
（36）　运行期的类型标识功能与C＋＋极为相似。例如，为获得与句柄　X　有关的信息，可使用下述代码：
X。getClass（）。getName（）；
为进行一个“类型安全”的紧缩造型，可使用：
derived　d　=　（derived）base；
这与旧式风格的C　造型是一样的。编译器会自动调用动态造型机制，不要求使用额外的语法。尽管它并不象　
C＋＋的“new　casts　”那样具有易于定位造型的优点，但Java　会检查使用情况，并丢弃那些“异常”，所以它　
不会象C＋＋那样允许坏造型的存在。
（37）　Java采取了不同的异常控制机制，因为此时已经不存在构建器。可添加一个finally　从句，强制执行　
特定的语句，以便进行必要的清除工作。Java　中的所有异常都是从基础类Throwable　里继承而来的，所以可　
确保我们得到的是一个通用接口。
public　void　f（Obj　b）　throws　IOException　｛
myresource　mr　=　b。createResource（）；
try　｛
mr。UseResource（）；
｝　catch　（MyException　e）　｛
//　handle　my　exception
｝　catch　（Throwable　e）　｛
//　handle　all　other　exceptions
｝　finally　｛
mr。dispose（）；　//　special　cleanup
｝
｝
（38）　Java的异常规范比C＋＋的出色得多。丢弃一个错误的异常后，不是象C＋＋那样在运行期间调用一个函　
数，Java　异常规范是在编译期间检查并执行的。除此以外，被取代的方法必须遵守那一方法的基础类版本的　
异常规范：它们可丢弃指定的异常或者从那些异常衍生出来的其他异常。这样一来，我们最终得到的是更为　
“健壮”的异常控制代码。
（39）　Java具有方法过载的能力，但不允许运算符过载。String　类不能用＋和＋=运算符连接不同的字串，而且　
String　表达式使用自动的类型转换，但那是一种特殊的内建情况。
（40）　通过事先的约定，C＋＋中经常出现的const　问题在Java　里已得到了控制。我们只能传递指向对象的句　
柄，本地副本永远不会为我们自动生成。若希望使用类似　C＋＋按值传递那样的技术，可调用　clone（），生成自　
变量的一个本地副本（尽管clone（）的设计依然尚显粗糙——参见第　12　章）。根本不存在被自动调用的副本　
675　
…………………………………………………………Page　677……………………………………………………………
构建器。为创建一个编译期的常数值，可象下面这样编码：
static　final　int　SIZE　=　255
static　final　int　BSIZE　=　8　*　SIZE
（41）　由于安全方面的原因，“应用程序”的编程与“程序片”的编程之间存在着显著的差异。一个最明显的　
问题是程序片不允许我们进行磁盘的写操作，因为这样做会造成从远程站点下载的、不明来历的程序可能胡　
乱改写我们的磁盘。随着Java　1。1　对数字签名技术的引用，这一情况已有所改观。根据数字签名，我们可确　
切知道一个程序片的全部作者，并验证他们是否已获得授权。Java　1。2　会进一步增强程序片的能力。
（42）　由于Java　在某些场合可能显得限制太多，所以有时不愿用它执行象直接访问硬件这样的重要任务。　
Java　解决这个问题的方案是“固有方法”，允许我们调用由其他语言写成的函数（目前只支持C　和C＋＋）。　
这样一来，我们就肯定能够解决与平台有关的问题（采用一种不可移植的形式，但那些代码随后会被隔离起　
来）。程序片不能调用固有方法，只有应用程序才可以。
（43）　Java提供对注释文档的内建支持，所以源码文件也可以包含它们自己的文档。通过一个单独的程序，　
这些文档信息可以提取出来，并重新格式化成　HTML　。这无疑是文档管理及应用的极大进步。
（44）　Java包含了一些标准库，用于完成特定的任务。C＋＋则依靠一些非标准的、由其他厂商提供的库。这些　
任务包括（或不久就要包括）：
?