《Thinking in Java》学习笔记——第七章：多形性

第七章：多形性
“对于面向对象的程序设计语言，多型性是第三种最基本的特征（前两种是数据抽象和继承。”
“多形性”（Polymorphism）从另一个角度将接口从具体的实施细节中分离出来，亦即实现了“是什么”与“怎样做”两个模块的分离。利用多形性的概念，代码的组织以及可读性均能获得改善。
7.1 上塑造型
取得一个对象句柄，并将其作为基础类型句柄使用的行为就叫作“上溯造型”——因为继承树的画法是基础类位于最上方。
7.1.1 为什么要上溯造型
如果一个基类有众多的衍生类，在调用某个基类方法的时候，如果不用多态，就必须为每个衍生类分别编写一个过载的方法。
7.2 深入理解
7.2.1 方法调用的绑定
将一个方法调用同一个方法主体连接到一起就称为“绑定”（Binding）。若在程序运行以前执行绑定（由编译器和链接程序，如果有的话），就叫作“早期绑定”。大家以前或许从未听说过这个术语，因为它在任何程序化语言里都是不可能的。解决的方法就是“后期绑定”，它意味着绑定在运行期间进行，以对象的类型为基础。后期绑定也叫作“动态绑定”或“运行期绑定”。
不同的语言对后期绑定的实现方法是有所区别的。但我们至少可以这样认为：它们都要在对象中安插某些特殊类型的信息。
Java 中绑定的所有方法都采用后期绑定技术，除非一个方法已被声明成final。这意味着我们通常不必决定是否应进行后期绑定——它是自动发生的。
7.2.2 产生正确的行为
知道Java 里绑定的所有方法都通过后期绑定具有多形性以后，就可以相应地编写自己的代码，令其与基础类沟通。此时，所有的衍生类都保证能用相同的代码正常地工作。或者换用另一种方法，我们可以“将一条消息发给一个对象，让对象自行判断要做什么事情。”
7.2.3 拓展性
由于存在多形性，所以可根据自己的需要向系统里加入任意多的新类型，同时毋需更改true()方法。我们说这样的程序具有“扩展性”，因为可以从通用的基础类继承新的数据类型，从而新添一些功能。如果是为了适应新类的要求，那么对基础类接口进行操纵的方法根本不需要改变。
7.3 覆盖与过载
7.4 抽象类和方法
在我们所有乐器（Instrument）例子中，基础类Instrument 内的方法都肯定是“伪”方法。若去调用这些方法，就会出现错误。那是由于Instrument 的意图是为从它衍生出去的所有类都创建一个通用接口。之所以要建立这个通用接口，唯一的原因就是它能为不同的子类型作出不同的表示。它为我们建立了一种基本形式，使我们能定义在所有衍生类里“通用”的一些东西。为阐述这个观念，另一个方法是把Instrument称为“抽象基础类”（简称“抽象类”）。若想通过该通用接口处理一系列类，就需要创建一个抽象类。对所有与基础类声明的签名相符的衍生类方法，都可以通过动态绑定机制进行调用
包含了抽象方法的一个类叫作“抽象类”。如果一个类里包含了一个或多个抽象方法，类就必须指定成abstract（抽象）。否则，编译器会向我们报告一条出错消息。
7.5 接口
“interface”（接口）关键字使抽象的概念更深入了一层。我们可将其想象为一个“纯”抽象类。它允许创建者规定一个类的基本形式：方法名、自变量列表以及返回类型，但不规定方法主体。接口也包含了基本数据类型的数据成员，但它们都默认为static 和final。接口这样描述自己：“对于实现我的所有类，看起来都应该象我现在这个样子”。因此，采用了一个特定接口的所有代码都知道对于那个接口可能会调用什么方法。这便是接口的全部含义。
为创建一个接口，请使用interface 关键字，而不要用class。为了生成与一个特定的接口（或一组接口）相符的类，要使用implements（实现）关键字。我们要表达的意
思是“接口看起来就象那个样子，这儿是它具体的工作细节”。
可决定将一个接口中的方法声明明确定义为“public”。但即便不明确定义，它们也会默认为public。所以在实现一个接口的时候，来自接口的方法必须定义成public。否则的话，它们会默认为“友好的”，而且会限制我们在继承过程中对一个方法的访问——Java 编译器不允许我们那样做。
7.5.1 Java的“多重继承”
接口只是比抽象类“更纯”的一种形式。它的用途并不止那些。由于接口根本没有具体的实施细节——也就是说，没有与存储空间与“接口”关联在一起——所以没有任何办法可以防止多个接口合并到一起。
一个类可以implements多个接口，一个接口也可以implements或者extends多个接口，从而组合成为新的接口，接口的名字只是简单的用逗号分隔。
7.5.3 常数分组
由于置入一个接口的所有字段都自动具有static 和final 属性，所以接口是对常数值进行分组的一个好工具，它具有与C 或C++的enum 非常相似的效果。
7.5.4 初始化接口中的字段
接口中定义的字段会自动具有static 和final 属性。它们不能是“空白final”，但可初始化成非常数表达式。
7.6 内部类
可将一个类定义置入另一个类定义中。这就叫作“内部类”。内部类对我们非常有用，因为利用它可对那些逻辑上相互联系的类进行分组，并可控制一个类在另一个类里的“可见性”。
若想在除外部类非static 方法内部之外的任何地方生成内部类的一个对象，必须将那个对象的类型设为“外部类名.内部类名”
7.6.1 内部类和上塑造型
当我们准备上溯造型到一个基础类（特别是到一个接口）的时候，内部类就开始发挥其关键作用（从用于实现的对象生成一个接口句柄具有与上溯造型至一个基础类相同的效果）。这是由于内部类随后可完全进入不可见或不可用状态——对任何人都将如此。所以我们可以非常方便地隐藏实施细节。我们得到的全部回报就是一个基础类或者接口的句柄，而且甚至有可能不知道准确的类型。
7.6.2 方法和作用域中的内部类
对那些涉及内部类的代码，通常表达的都是“单纯”的内部类，非常简单，且极易理解。然而，内部类的设计非常全面，不可避免地会遇到它们的其他大量用法——假若我们在一个方法甚至一个任意的作用域内创建内部类。有两方面的原因促使我们这样做：
(1) 正如前面展示的那样，我们准备实现某种形式的接口，使自己能创建和返回一个句柄。
(2) 要解决一个复杂的问题，并希望创建一个类，用来辅助自己的程序方案。同时不愿意把它公开。
若想对匿名内部类的一个对象进行某种形式的初始化，此时会出现什么情况呢？由于它是匿名的，没有名字赋给构建器，所以我们不能拥有一个构建器。
若试图定义一个匿名内部类，并想使用在匿名内部类外部定义的一个对象，则编译器要求外部对象为final属性。
7.6.3 链接到外部类
迄今为止，我们见到的内部类好象仅仅是一种名字隐藏以及代码组织方案。尽管这些功能非常有用，但似乎并不特别引人注目。然而，我们还忽略了另一个重要的事实。创建自己的内部类时，那个类的对象同时拥有指向封装对象（这些对象封装或生成了内部类）的一个链接。所以它们能访问那个封装对象的成员——毋需取得任何资格。除此以外，内部类拥有对封装类所有元素的访问权限。
7.6.4 static内部类
为正确理解static 在应用于内部类时的含义，必须记住内部类的对象默认持有创建它的那个封装类的一个对象的句柄。然而，假如我们说一个内部类是static 的，这种说法却是不成立的。static 内部类意味着：
(1) 为创建一个static 内部类的对象，我们不需要一个外部类对象。
(2) 不能从static 内部类的一个对象中访问一个外部类对象。
但在存在一些限制：由于static 成员只能位于一个类的外部级别，所以内部类不可拥有static 数据或static 内部类。
倘若为了创建内部类的对象而不需要创建外部类的一个对象，那么可将所有东西都设为static。为了能正常工作，同时也必须将内部类设为static。
7.6.5 引用外部类对象
若想生成外部类对象的句柄，就要用一个点号以及一个this 来命名外部类。举个例子来说，在Sequence.SSelector 类中，它的所有方法都能产生外部类Sequence 的存储句柄，方法是采用Sequence.this的形式。结果获得的句柄会自动具备正确的类型（这会在编译期间检查并核实，所以不会出现运行期的开销）。
有些时候，我们想告诉其他某些对象创建它某个内部类的一个对象。为达到这个目的，必须在new 表达式中提供指向其他外部类对象的一个句柄。
因此，除非已拥有外部类的一个对象，否则不可能创建内部类的一个对象。这是由于内部类的对象已同创建它的外部类的对象“默默”地连接到一起。然而，如果生成一个static 内部类，就不需要指向外部类对象的一个句柄。
7.6.6 从内部类继承
由于内部类构建器必须同封装类对象的一个句柄联系到一起，所以从一个内部类继承的时候，情况会稍微变得有些复杂。这儿的问题是封装类的“秘密”句柄必须获得初始化，而且在衍生类中不再有一个默认的对象可以连接。
必须在扩展类构建器中采用下述语法：
enclosingClassHandle.super();
它提供了必要的句柄，以便程序正确编译。
7.6.7 内部类可以覆盖吗？
若创建一个内部类，然后从封装类继承，并重新定义内部类，那么会出现什么情况呢？也就是说，我们有可能覆盖一个内部类吗？
当我们从外部类继承的时候，没有任何额外的内部类继续下去。然而，仍然有可能“明确”地从内部类继承。
7.6.8 内部类标识符
由于每个类都会生成一个.class 文件，用于容纳与如何创建这个类型的对象有关的所有信息（这种信息产生了一个名为Class 对象的元类），所以大家或许会猜到内部类也必须生成相应的.class 文件，用来容纳与它们的Class 对象有关的信息。这些文件或类的名字遵守一种严格的形式：先是封装类的名字，再跟随一个$，再跟随内部类的名字。
如果内部类是匿名的，那么编译器会简单地生成数字，把它们作为内部类标识符使用。若内部类嵌套于其他内部类中，则它们的名字简单地追加在一个$以及外部类标识符的后面。
7.6.9 为什么要用内部类：控制框架
到目前为止，大家已接触了对内部类的运作进行描述的大量语法与概念。但这些并不能真正说明内部类存在的原因。为什么Sun 要如此麻烦地在Java 1.1 里添加这样的一种基本语言特性呢？答案就在于我们在这里要学习的“控制框架”。
一个“应用程序框架”是指一个或一系列类，它们专门设计用来解决特定类型的问题。为应用应用程序框架，我们可从一个或多个类继承，并覆盖其中的部分方法。我们在覆盖方法中编写的代码用于定制由那些应用程序框架提供的常规方案，以便解决自己的实际问题。“控制框架”属于应用程序框架的一种特殊类型，受到对事件响应的需要的支配；主要用来响应事件的一个系统叫作“由事件驱动的系统”。在应用程序设计语言中，最重要的问题之一便是“图形用户界面”（GUI），它几乎完全是由事件驱动的。正如大家会在第13 章学习的那样，Java 1.1 AWT 属于一种控制框架，它通过内部类完美地解决了GUI 的问题。
7.7 构建器和多形性
同往常一样，构建器与其他种类的方法是有区别的。在涉及到多形性的问题后，这种方法依然成立。
7.7.1 构建器的调用顺序
对于一个复杂的对象，构建器的调用遵照下面的顺序：
(1) 调用基础类构建器。这个步骤会不断重复下去，首先得到构建的是分级结构的根部，然后是下一个衍生类，等等。直到抵达最深一层的衍生类。
(2) 按声明顺序调用成员初始化模块。
(3) 调用衍生构建器的主体。
若坚持按这一规则行事，会有助于我们确定所有基础类成员以及当前对象的成员对象均已获得正确的初始化。但不幸的是，这种做法并不适用于所有情况，这将在下一节具体说明。
7.7.2 继承和finalize()
覆盖衍生类的finalize()时，务必记住调用finalize()的基础类版本。否则，基础类的初始化根本不会发生。
7.7.3 构建器内部的多形性方法的行为
但实际情况并非完全如此。若调用构建器内部一个动态绑定的方法，会使用那个方法被覆盖的定义。然而，产生的效果可能并不如我们所愿，而且可能造成一些难于发现的程序错误。
前一节讲述的初始化顺序并不十分完整，而那是解决问题的关键所在。初始化的实际过程是这样的：
(1) 在采取其他任何操作之前，为对象分配的存储空间初始化成二进制零。
(2) 就象前面叙述的那样，调用基础类构建器。此时，被覆盖的draw()方法会得到调用（的确是在RoundGlyph 构建器调用之前），此时会发现radius 的值为0，这是由于步骤(1)造成的。
(3) 按照原先声明的顺序调用成员初始化代码。
(4) 调用衍生类构建器的主体。
因此，设计构建器时一个特别有效的规则是：用尽可能简单的方法使对象进入就绪状态；如果可能，避免调用任何方法。在构建器内唯一能够安全调用的是在基础类中具有final 属性的那些方法（也适用于private方法，它们自动具有final 属性）。这些方法不能被覆盖，所以不会出现上述潜在的问题。
7.8 通过继承进行设计
7.8.1 纯继承与扩展
7.8.2 下溯造型与运行期类型标识
第十一章整章讲述的都是Java运行期类型标识的方方面面。