zoukankan      html  css  js  c++  java
  • ThinkJava-多态

    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
    *///:~
    View Code
    当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()
    *///:~
    View Code
    静态方法是与类,而并非与单个的对象相关联的。
     
     
    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 ) ,只要有可能,就应该对它们进行初始化(也就是说,
    通过组合方法将对象置于类内)。若遵循这一规则,那么就能保证所有基类成员以及当前对象的
    成员对象都被初始化了。但遗憾的是,这种做法并不适用于所有情况,这一点我们会在下一节
    中看到。
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
    ----------------
  • 相关阅读:
    Redis学习六(java中使用redis)
    Redis学习五(新数据类型)
    Redis学习四(发布和订阅)
    Redis学习三(配置文件说明)
    Redis学习二(常用五大数据类型)
    Redis学习一(源码安装redis)
    RocketMq常见问题记录
    总结多种容器化技术对比
    关于Redis集群部署和持久化的相关问题
    配置Jenkins连接kubernetes的Pod Template模板
  • 原文地址:https://www.cnblogs.com/tenWood/p/8419724.html
Copyright © 2011-2022 走看看