Vertiefte Java-Kenntnisse der dynamischen Bindung

In objektorientierten Programmiersprachen ist Polymorphismus nach Datenabstraktion und -vererbung das dritte Grundmerkmal. Polymorphismus trennt die Schnittstelle und die Implementierung aus einer anderen Perspektive, indem er trennt, was zu tun ist und wie es zu tun ist. Wenn wir zum ersten Mal mit dem Wort „Polymorphismus“ in Berührung kommen, sind wir möglicherweise durch das Wort selbst verwirrt. Wenn wir „Polymorphismus“ in „dynamische Bindung“ ändern, können meiner Meinung nach viele Menschen seine tiefere Bedeutung verstehen. Normalerweise nennen wir dynamische Bindung späte Bindung und Laufzeitbindung.

(1) Methodenaufrufbindung

1 Bindungskonzept

Normalerweise rufen wir eine Methode mit demselben A auf Der Methodenkörper ist einer -Bindung zugeordnet. Wenn die Bindung vor der Programmausführung erfolgt, nennen wir diese Bindungsmethode frühe Bindung. In prozeduralen Sprachen wie C ist diese Methode die einzige Standardmethode. Wenn wir in Java die frühe Bindung verwenden, ist es sehr wahrscheinlich, dass der Compiler verwirrt ist, welche Methode er in diesem riesigen Vererbungsimplementierungssystem binden soll. Die Lösung ist dynamische Bindung. Diese späte Bindungsmethode bindet je nach Objekttyp zur Laufzeit.

In Java ist dynamische Bindung das Standardverhalten. Aber in einer Klasse verwenden gewöhnliche Methoden diese dynamische Bindungsmethode, und es gibt auch Situationen, in denen die dynamische Bindung nicht auf natürliche Weise erfolgt.

2.endgültige Änderung

Wenn eine Eigenschaft durch final geändert wird, bedeutet dies: Sie kann nach der Initialisierung nicht mehr geändert werden.
Wenn eine Methode durch final geändert wird, bedeutet dies, dass sie nicht überschrieben werden kann. Wir sagen das oft gerne aus der Makroperspektive, aber warum können unsere Methoden, die tatsächlich durch final geändert werden, nicht überschrieben werden? Weil der letzte Modifikator die dynamische Bindung tatsächlich deaktiviert. In Java kann der durch final geänderte Inhalt nicht dynamisch gebunden werden. Ohne dynamische Bindung gibt es kein Konzept des Polymorphismus und kann natürlich nicht überschrieben werden.

3. Private Methoden „überschreiben“

Tatsächlich legen wir Methoden selten als privat fest. Wenn wir die private Methode „überschreiben“, erhalten wir tatsächlich eine neue Methode. Es hat überhaupt nichts mit der übergeordneten Klasse zu tun. Darauf sollten Sie während des Interviews achten: Das „Überschreiben“ der privaten Methoden der übergeordneten Klasse in der Unterklasse ist zulässig, ohne dass ein Fehler gemeldet wird. Es handelt sich lediglich um zwei völlig unabhängige Methoden.

4. Domänen und statische Methoden

Wenn wir Polymorphismus verstehen, denken wir vielleicht, dass alle Dinge polymorph auftreten können. Eigentlich nicht, Wenn wir direkt auf eine Domain zugreifen, wird dieser Zugriff während der Kompilierung geparst Wir können uns auf das folgende Beispiel beziehen:

package Polymorphic;/**
 * 
 * @author QuinnNorris
 * 域不具有多态性
 */public class polymorphics {

    /**
     * @param args
     */
    public static void main(String[] args) {        // TODO Auto-generated method stub
        Super sup = new Sub();
        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());
    }

}

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;
    }
}

Ausgabeergebnis:

 sup.field = 0, sup.getField() = 1 

  sub.field = 1, sub.getField() = 1, sub.getSuperField() = 0

Dieses Beispiel zeigt uns, dass beim Aufrufen einer Methode der Körper, der auswählt, welche Methode ausgeführt werden soll, zur Laufzeit dynamisch ausgewählt wird. Wenn wir jedoch direkt auf das Instanzfeld zugreifen, greift der Compiler entsprechend dem durch dieses Objekt dargestellten Typ direkt darauf zu. Die gleiche Situation besteht für statische Methoden. So können wir diese Zusammenfassung erstellen:

1. Normale Methode: dynamische Bindung entsprechend der Art der Objektentität

2. Domäne und statische Methode : Frühe Bindung entsprechend dem durch das Objekt dargestellten Typ

Laienhaft ausgedrückt: Bei gewöhnlichen Methoden betrachten wir den Typ nach neuen; bei Domänen- und statischen Methoden suchen wir at = front Welcher Typ deklariert wird.
Obwohl dies eine sehr verwirrende Frage zu sein scheint. In der Praxis kommt dies jedoch nie (oder selten) vor. Erstens wurden Programmierer, die Instanzfelder nicht auf „privat“ setzen, grundsätzlich gefeuert (Instanzfelder werden selten so geändert, dass sie öffentlich sind). Zweitens legen wir selten fest, dass die Felder, die wir in der Unterklasse erstellen, denselben Namen haben wie die übergeordnete Klasse.

(2) Konstruktor und Polymorphismus

Im Allgemeinen ist der Konstruktor eine sehr einzigartige Existenz. Das Gleiche gilt, wenn es um Polymorphismus geht. Obwohl Konstruktoren nicht polymorph sind (tatsächlich sind sie mit Statik versehen, obwohl Statik implizit deklariert wird), ist es dennoch notwendig, die Funktionsweise von Konstruktoren zu verstehen.

1. Die Aufrufreihenfolge von Konstruktoren

Der Konstruktor der übergeordneten Klasse wird immer während des Aufrufs des Konstruktors der Unterklasse aufgerufen Vererbung Links schrittweise nach oben, damit der Konstruktor jeder übergeordneten Klasse korrekt aufgerufen werden kann. Dies ist notwendig, da der Konstruktor eine besondere Aufgabe hat, nämlich zu prüfen, ob das Objekt korrekt konstruiert wurde. Unterklassenmethoden können nur auf ihre eigenen Mitglieder zugreifen, nicht auf Mitglieder der übergeordneten Klasse. Nur der Basisklassenkonstruktor verfügt über die entsprechenden Berechtigungen zum Initialisieren seiner eigenen Elemente. Daher muss jeder Konstruktor aufgerufen werden, andernfalls kann kein korrektes und vollständiges Objekt erstellt werden.

package Polymorphic;

public class Father {

    /**
     * @param args
     */
    public static void main(String[] args) {        // TODO Auto-generated method stub
        new F();
    }

}class A {
    A() {
        System.out.println("A");
    }
}class B extends A {
    B() {
        System.out.println("B");
    }
}class C extends B {
    C() {
        System.out.println("C");
    }
}class D {
    D() {
        System.out.println("D");
    }
}class E {
    E() {
        System.out.println("E");
    }
}class F extends C {
    private D d = new D();    private E e = new E();

    F() {
        System.out.println("F");
    }
}

Ausgabeergebnis:

 A 

  B 

  C 

  D 

  E 

  F

Ausgabeergebnis von scheinbar zufälligem „ABCDEF“, tatsächlich , wir haben es sorgfältig arrangiert.
Dieses Beispiel veranschaulicht sehr intuitiv die Konstruktoraufrufregel, die die folgenden drei Schritte umfasst:

1. 调用父类构造器。这个步骤会反复递归进去，直到最祖先的类，依次向下调用构造器。

2. 按声明顺序调用成员的初始化构造器方法。

3. 调用子类构造器的主体。

可能我说了这个顺序，大家马上就会想到super。是的没错，super（）确实可以显示的调用父类中自己想要调用的构造方法，但是super（）必须放在构造器的第一行，这个是规定。我们的顺序是没有任何问题的，或者说其实在F的构造器中第一句是super（）。只不过我们默认省略了。

（三）协变返回类型特性

java在se5中添加了协变返回类型，它表示在子类中的被覆盖方法可以返回父类这个方法的返回类型的某种子类。

package Polymorphic;/**
 * 
 * @author QuinnNorris
 * 协变返回类型
 */public class covariant {

    /**
     * @param args
     */
    public static void main(String[] args) {        // TODO Auto-generated method stub

        A b = new B();
        b.getC().print();

        A a = new A();
        a.getC().print();
    }

}class A{
    public C getC() {        return new C();
    }
}class B extends A{
    public D getC(){        return new D();
    }
}class C{
    public void print(){
        System.out.println("C");
    }
}class D extends C{
    public void print(){
        System.out.println("D");
    }
}

输出结果：

 D 

  C

在上面的例子中，D类是继承于C类的，B类是继承于A类的，所以在B类覆盖的getC方法中，可以将返回类型协变成，C类的某个子类（D类）的类型。

（四）继承设计

通常，继承并不是我们的首选，能用组合的方法尽量用组合，这种手段更灵活，如果你的代码中is-a和is-like-a过多，你就应该考虑考虑是不是该换成has-a一些了。一条通用的准则是：用继承表达行为间的差异，并用字段表达状态上的变化。

而且在用继承的时候，我们会经常涉及到向上转型和向下转型。在java中，所有的转型都会得到检查。即使我们只是进行一次普通的加括号的类型转换，在进入运行期时仍然会对其进行检查，以便保证它的确是我们希望的那种类型。如果不是，就返回一个ClassCastException（类转型异常）。这种在运行期间对类型进行检查的行为称作”运行时类型识别（RTTI）“。

在面向对象的程序设计语言中，多态是继数据抽象和继承之后的第三种基本特性。多态通过分离做什么和怎么做，从另一个角度将接口和实现分离开来。在一开始接触多态这个词的时候，我们或许会因为这个词本身而感到困惑，如果我们把多态改称作“动态绑定”，相信很多人就能理解他的深层含义。通常的，我们把动态绑定也叫做后期绑定，运行时绑定。

（一）方法调用绑定

1.绑定概念

通常，我们将一个方法调用同一个方法主体关联起来称作绑定。如果在程序执行前进行绑定，我们将这种绑定方法称作前期绑定。在面向过程语言中，比如c，这种方法是默认的也是唯一的。如果我们在java中采用前期绑定，很有可能编译器会因为在这庞大的继承实现体系中去绑定哪个方法而感到迷惑。解决的办法就是动态绑定，这种后期绑定的方法，在运行的时候根据对象的类型进行绑定。

在java中，动态绑定是默认的行为。但是在类中，普通的方法会采用这种动态绑定的方法，也有一些情况并不会自然的发生动态绑定。

2.final修饰

如果一个属性被final修饰，则含义是：在初始化之后不能被更改。
如果一个方法被final修饰，含义则是不能被覆盖。我们常常喜欢从宏观的角度这样说，但是我们真正的被final修饰的方法为什么不能被覆盖呢？因为final修饰词其实实际上关闭了动态绑定。在java中被final修饰的内容不能采用动态绑定的方法，不能动态绑定就没有多态的概念，自然也就不能被覆盖。

3.“覆盖”私有方法

其实我们很少把方法设定为私有。如果我们将private方法“覆盖”掉，其实我们获得的只是一个新的方法。完全和父类没关系了。这一点要注意，或许面试的时候会被问到：在子类中“覆盖”父类私有方法是被允许而不报错的，只不过完全是两个没关系的方法罢了。

4.域与静态方法

当我们了解了多态性之后可能会认为所有的事物都是可以多态地发生。其实并不是，如果我们直接访问某个域，这个访问会在编译期进行解析，我们可以参考下面的例子：

package Polymorphic;/**
 * 
 * @author QuinnNorris
 * 域不具有多态性
 */public class polymorphics {

    /**
     * @param args
     */
    public static void main(String[] args) {        // TODO Auto-generated method stub
        Super sup = new Sub();
        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());
    }

}

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;
    }
}

输出结果：
 

sup.field = 0, sup.getField() = 1 

  sub.field = 1, sub.getField() = 1, sub.getSuperField() = 0

这个例子告诉我们，当我们调用一个方法时，去选择执行哪个方法的主体是运行时动态选择的。但是当我们直接访问实例域的时候，编译器直接按照这个对象所表示的类型来访问。于此情况完全相同的还有静态方法。所以我们可以做出这种总结：

1. 普通方法：根据对象实体的类型动态绑定

2. 域和静态方法：根据对象所表现的类型前期绑定

通俗地讲，普通的方法我们看new后面的是什么类型；域和静态方法我们看=前面声明的是什么类型。
尽管这看来好像是一个非常容易让人混悬哦的问题。但是在实践中，实际上从来（或者说很少）不会发生。首先，那些不把实例域设置为private的程序员基本上已经全都被炒鱿鱼了（实例域很少被修饰成public）。其次我们很少会将自己在子类中创建的域设置成和父类一样的名字。

（二）构造器与多态

通常，构造器是一个很独特的存在。涉及到多态的时候也是如此。尽管构造器并不具有多态性（实际上他们是有static来修饰的，尽管该static是被隐式声明的），但是我们还是有必要理解一下构造器的工作原理。

1.构造器的调用顺序

父类的构造器总是在子类构造器调用的过程中被调用，而且按照继承层次逐渐向上的链接，以使每个父类的构造器都能被正确的调用。这样做是很有必要的，因为构造器有一项特殊的任务，检查对象是否被正确的构造。子类方法只能访问自己的成员，不能访问父类中的成员。只有基类的构造器才具有恰当的权限对自己的元素进行初始化。因此必须要让每个构造器都能得到调用，否则不能构造出正确的完整的对象。

package Polymorphic;

public class Father {

    /**
     * @param args
     */
    public static void main(String[] args) {        // TODO Auto-generated method stub
        new F();
    }

}class A {
    A() {
        System.out.println("A");
    }
}class B extends A {
    B() {
        System.out.println("B");
    }
}class C extends B {
    C() {
        System.out.println("C");
    }
}class D {
    D() {
        System.out.println("D");
    }
}class E {
    E() {
        System.out.println("E");
    }
}class F extends C {
    private D d = new D();    private E e = new E();

    F() {
        System.out.println("F");
    }
}

输出结果：

 A 

  B 

  C 

  D 

  E 

  F

看似偶然的“ABCDEF”的输出结果，实际上是我们精心安排的。
这个例子非常直观的说明了构造器的调用法则，有以下三个步骤：

1. 调用父类构造器。这个步骤会反复递归进去，直到最祖先的类，依次向下调用构造器。

2. 按声明顺序调用成员的初始化构造器方法。

3. 调用子类构造器的主体。

可能我说了这个顺序，大家马上就会想到super。是的没错，super（）确实可以显示的调用父类中自己想要调用的构造方法，但是super（）必须放在构造器的第一行，这个是规定。我们的顺序是没有任何问题的，或者说其实在F的构造器中第一句是super（）。只不过我们默认省略了。

（三）协变返回类型特性

java在se5中添加了协变返回类型，它表示在子类中的被覆盖方法可以返回父类这个方法的返回类型的某种子类。

package Polymorphic;/**
 * 
 * @author QuinnNorris
 * 协变返回类型
 */public class covariant {

    /**
     * @param args
     */
    public static void main(String[] args) {        // TODO Auto-generated method stub

        A b = new B();
        b.getC().print();

        A a = new A();
        a.getC().print();
    }

}class A{
    public C getC() {        return new C();
    }
}class B extends A{
    public D getC(){        return new D();
    }
}class C{
    public void print(){
        System.out.println("C");
    }
}class D extends C{
    public void print(){
        System.out.println("D");
    }
}

输出结果：

 D 

  C

在上面的例子中，D类是继承于C类的，B类是继承于A类的，所以在B类覆盖的getC方法中，可以将返回类型协变成，C类的某个子类（D类）的类型。

（四）继承设计

通常，继承并不是我们的首选，能用组合的方法尽量用组合，这种手段更灵活，如果你的代码中is-a和is-like-a过多，你就应该考虑考虑是不是该换成has-a一些了。一条通用的准则是：用继承表达行为间的差异，并用字段表达状态上的变化。

而且在用继承的时候，我们会经常涉及到向上转型和向下转型。在java中，所有的转型都会得到检查。即使我们只是进行一次普通的加括号的类型转换，在进入运行期时仍然会对其进行检查，以便保证它的确是我们希望的那种类型。如果不是，就返回一个ClassCastException（类转型异常）。这种在运行期间对类型进行检查的行为称作”运行时类型识别（RTTI）“。

 以上就是java深入理解动态绑定的内容，更多相关内容请关注PHP中文网（www.php.cn）！