8.2.1 方法调用绑定
解决的办法就是后期绑定,它的含义就是在运行时根据对象的类型进行绑定。后期绑定也
叫做动态绑定或运行时绑定.如果一种语言想实现后期绑定,就必须具有某种机制,以便在运
行时能判断对象的类型,从而调用恰当的方法。也就是说,编译器一直不知道对象的类型,但
是方法调用机制能找到正确的方法体,并加以调用。后期绑定机制随编程语言的不同而有所不
同,但是只要想一下就会得知,不管怎样都必须在对象中安置某种"类型信息"。
Java中除了static方法和final方法( private方法属于final方法)之外,其他所有的方法都是
后期绑定。这意味着通常情况下,我们不必判定是否应该进行后期绑定一一它会自动发生。
为什么要将某个方法声明为final呢?正如前一章提到的那样,它可以防止其他人覆盖该方
法。但更重要的一点或许是:这样做可以有效地"关闭"动态绑定,或者说,告诉编译器不需
要对其进行动态绑定。这样,编译器就可以为final方法调用生成更有效的代码。然而,大多数
情况下,这样做对程序的整体性能不会有什么改观。所以,最好根据设计来决定是否使用final ,
而不是出于试图提高性能的目的来使用final .
8.2.4缺陷:"覆盖"私有方法
例子:
package com.cy.polymorphism; // Trying to override a private method. import static com.java.util.Print.*; public class PrivateOverride { private void f() { print("private f()"); } public static void main(String[] args) { PrivateOverride po = new Derived(); po.f(); } } class Derived extends PrivateOverride { public void f() { print("public f()"); } } /* Output: private f() *///:~
我们所期望的输出是public f(). 但是由于private方法被自动认为是final方法, 而且对导出
类是屏蔽的。因此,在这种情况下, Derived类中的f()方法就是一个全新的方怯,既然基类中的
f()方法在子类Derived中不可见,因此甚至也不能被重载。
结论就是:只有非private方法才可以被覆盖;但是还需要密切注意覆盖private方法的现象,
这时虽然编译器不会报错,但是也不会按照我们所期望的来执行。确切地说,在导出类中,对
于基类中的private方法,最好采用不同的名字。
8.2.5 缺陷:域与静态方法
一旦你了解了多态机制,可能就会开始认为所有事物都可以多态地发生。然而,只有普通
的方法调用可以是多态的。例如,如果你直接访问某个域,这个访问就将在编译期进行解析,
就像下面的示例所演示的:
package com.cy.polymorphism; // Direct field access is determined at compile time. class Super { public int field = 0; public int getField() { return field; } } class Sub extends Super { public int field = 1; public int getField() { return field; } public int getSuperField() { return super.field; } } public class FieldAccess { public static void main(String[] args) { Super sup = new Sub(); // Upcast System.out.println("sup.field = " + sup.field +", sup.getField() = " + sup.getField()); Sub sub = new Sub(); System.out.println("sub.field = " + sub.field + ", sub.getField() = " + sub.getField() +", sub.getSuperField() = " + sub.getSuperField()); } } /* Output: sup.field = 0, sup.getField() = 1 sub.field = 1, sub.getField() = 1, sub.getSuperField() = 0 *///:~
当Sub对象转型为Super引用肘,任何域访问操作都将由编译器解析,因此不是多态的。在
本例中,为Super.field和Sub.fleld分配了不同的存储空间。这样, Sub实际上包含两个称为fleld
的域:它自己的和它从Super处得到的.然而,在引用Sub中的field时所产生的默认域并非Super
版本的field域。因此,为了得到Super.field ,必须显式地指明super.field .
尽管这看起来好像会成为一个容易令人棍淆的问题,但是在实践中,它实际上从来不会发
生.首先,你通常会将所有的域都设置成private,因此不能直接访问它们,其副作用是只能调
用方法来访问.另外,你可能不会对基类中的域和导出类中的域赋予相同的名字,因为这种做
法容易令人混淆。
如果某个方法是静态的,它的行为就不具有多态性:
package com.cy.polymorphism; // Static methods are not polymorphic. class StaticSuper { public static String staticGet() { return "Base staticGet()"; } public String dynamicGet() { return "Base dynamicGet()"; } } class StaticSub extends StaticSuper { public static String staticGet() { return "Derived staticGet()"; } public String dynamicGet() { return "Derived dynamicGet()"; } } public class StaticPolymorphism { public static void main(String[] args) { StaticSuper sup = new StaticSub(); // Upcast System.out.println(sup.staticGet()); System.out.println(sup.dynamicGet()); } } /* Output: Base staticGet() Derived dynamicGet() *///:~
静态方法是与类,而并非与单个的对象相关联的。
8.3 构造器和多态
通常,构造器不同于其他种类的方法.涉及到多态时仍是如此.尽管构造器并不具有多态
性(它们实际上是static方法,只不过该static声明是隐式的) .但还是非常有必要理解构造器怎
样通过多态在复杂的层次结构中运作,这一理解将有助于大家避免一些令人不快的困扰.
8.3.1 构造器的调用顺序
让我们来看下面这个例子,它展示组合、继承以及多态在构建顺序上的作用:
package com.cy.polymorphism; // Order of constructor calls. import static com.java.util.Print.*; class Meal { Meal() { print("Meal()"); } } class Bread { Bread() { print("Bread()"); } } class Cheese { Cheese() { print("Cheese()"); } } class Lettuce { Lettuce() { print("Lettuce()"); } } class Lunch extends Meal { Lunch() { print("Lunch()"); } } class PortableLunch extends Lunch { PortableLunch() { print("PortableLunch()");} } public class Sandwich extends PortableLunch { private Bread b = new Bread(); private Cheese c = new Cheese(); private Lettuce l = new Lettuce(); public Sandwich() { print("Sandwich()"); } public static void main(String[] args) { new Sandwich(); } } /* Output: Meal() Lunch() PortableLunch() Bread() Cheese() Lettuce() Sandwich() *///:~
在这个例子中,用其他类创建了一个复杂的类,而且每个类都有一个声明它自己的构造器.
其中最重要的类是Sandwich ,它反映了三层继承(若将自Object的隐含继承也算在内,就是四,
层)以及三个成员对象。当在main()里创建一个Sandwich对象后,就可以看到输出结果。这也
表明了这一复杂对象调用构造器要遵照下面的顺序:
1) 调用基类构造器。这个步骤会不断地反复递归下去,首先是构造这种层次结构的根,然
后是下一层导出类,等等,直到最低层的导出类。
2) 按声明顺序调用成员的初始化方法。
3) 调用导出类构造器的主体。
构造器的调用顺序是很重要的。当进行继承肘,我们已经知道基类的一切,并且可以访问
基类中任何声明为public和protected的成员。这意味着在导出类中,必须假定基类的所有成员
都是有效的。一种标准方法是,构造动作一经发生,那么对象所有部分的全体成员都会得到构
建。然而,在构造器内部,我们必须确保所要使用的成员都已经构建完毕。为确保这一目的,
唯一的办法就是首先调用基类构造器。那么在进入导出类构造器时,在基类中可供我们访问的
成员都已得到初始化。此外,知道构造器中的所有成员都有效也是因为, 当成员对象在类内进
行定义的时候(比如上例中的b 、c和l ) ,只要有可能,就应该对它们进行初始化(也就是说,
通过组合方法将对象置于类内)。若遵循这一规则,那么就能保证所有基类成员以及当前对象的
成员对象都被初始化了。但遗憾的是,这种做法并不适用于所有情况,这一点我们会在下一节
中看到。
----------------