Warum müssen this() und super() die erste Anweisung in einem Konstruktor sein?

Question

Java schreibt vor, dass der Aufruf von this() oder super() in einem Konstruktor die erste Anweisung sein muss. Warum?

Zum Beispiel:

public class MyClass {
    public MyClass(int x) {}
}

public class MySubClass extends MyClass {
    public MySubClass(int a, int b) {
        int c = a + b;
        super(c);  // COMPILE ERROR
    }
}

Der Sun-Compiler sagt: "Der Aufruf von super muss die erste Anweisung im Konstruktor sein". Der Eclipse-Compiler sagt: "Constructor call must be the first statement in a constructor".

Sie können dies jedoch umgehen, indem Sie den Code ein wenig umgestalten:

public class MySubClass extends MyClass {
    public MySubClass(int a, int b) {
        super(a + b);  // OK
    }
}

Hier ein weiteres Beispiel:

public class MyClass {
    public MyClass(List list) {}
}

public class MySubClassA extends MyClass {
    public MySubClassA(Object item) {
        // Create a list that contains the item, and pass the list to super
        List list = new ArrayList();
        list.add(item);
        super(list);  // COMPILE ERROR
    }
}

public class MySubClassB extends MyClass {
    public MySubClassB(Object item) {
        // Create a list that contains the item, and pass the list to super
        super(Arrays.asList(new Object[] { item }));  // OK
    }
}

Es ist also Sie nicht daran hindern, die Logik auszuführen vor dem Anruf beim Hausmeister. Es hält Sie nur davon ab, Logik auszuführen, die Sie nicht in einen einzigen Ausdruck packen können.

Es gibt ähnliche Regeln für den Aufruf this() . Der Compiler sagt: "Der Aufruf von this muss die erste Anweisung im Konstruktor sein".

Warum hat der Compiler diese Einschränkungen? Können Sie ein Codebeispiel nennen, bei dem etwas Schlimmes passieren würde, wenn der Compiler diese Einschränkung nicht hätte?

Answer 1

Es ist sinnvoll, dass die Konstruktoren ihre Ausführung in der Reihenfolge von Ableitung. Da eine Oberklasse keine Kenntnis von einer Unterklasse hat, ist jede Initialisierung, die sie durchführen muss, getrennt von und möglicherweise Voraussetzung für jede Initialisierung, die von der Unterklasse durchgeführt wird. Daher muss sie ihre Ausführung zuerst abschließen.

Eine einfache Demonstration:

class A {
    A() {
        System.out.println("Inside A's constructor.");
    }
}

class B extends A {
    B() {
        System.out.println("Inside B's constructor.");
    }
}

class C extends B {
    C() {
        System.out.println("Inside C's constructor.");
    }
}

class CallingCons {
    public static void main(String args[]) {
        C c = new C();
    }
}

Die Ausgabe dieses Programms lautet:

Inside A's constructor
Inside B's constructor
Inside C's constructor

Answer 2

Ich habe eine Abhilfe gefunden.

Das lässt sich nicht kompilieren:

public class MySubClass extends MyClass {
    public MySubClass(int a, int b) {
        int c = a + b;
        super(c);  // COMPILE ERROR
        doSomething(c);
        doSomething2(a);
        doSomething3(b);
    }
}

Das funktioniert:

public class MySubClass extends MyClass {
    public MySubClass(int a, int b) {
        this(a + b);
        doSomething2(a);
        doSomething3(b);
    }

    private MySubClass(int c) {
        super(c);
        doSomething(c);
    }
}

Answer 3

Ich vermute, dass sie dies getan haben, um das Leben derjenigen zu erleichtern, die Tools zur Verarbeitung von Java-Code schreiben, und in geringerem Maße auch derjenigen, die Java-Code lesen.

Wenn Sie die super() o this() Aufforderung, sich zu bewegen, gibt es mehr Varianten, auf die man achten muss. Wenn Sie zum Beispiel die super() o this() Aufruf in eine bedingte if() muss es möglicherweise so intelligent sein, dass es eine implizite super() in die else . Es muss möglicherweise wissen, wie man einen Fehler meldet, wenn man super() zweimal, oder verwenden Sie super() y this() zusammen. Möglicherweise müssen Methodenaufrufe beim Empfänger untersagt werden, bis super() o this() aufgerufen wird, und herauszufinden, wann dies der Fall ist, wird kompliziert.

Dass alle diese zusätzliche Arbeit machen mussten, schien wahrscheinlich mehr Kosten als Nutzen zu bringen.

Answer 4

Sie können anonyme Initialisierungsblöcke verwenden, um Felder im Kind zu initialisieren, bevor Sie dessen Konstruktor aufrufen. Dieses Beispiel zeigt:

public class Test {
    public static void main(String[] args) {
        new Child();
    }
}

class Parent {
    public Parent() {
        System.out.println("In parent");
    }
}

class Child extends Parent {

    {
        System.out.println("In initializer");
    }

    public Child() {
        super();
        System.out.println("In child");
    }
}

Dies führt zur Ausgabe von :

Bei Eltern
Im Initialisierer
Im Kind

Answer 5

Ich weiß, dass ich ein bisschen spät dran bin, aber ich habe diesen Trick schon ein paar Mal angewandt (und ich weiß, dass er etwas ungewöhnlich ist):

Ich erstelle eine generische Schnittstelle InfoRunnable<T> mit einer Methode:

public T run(Object... args);

Und wenn ich etwas tun muss, bevor ich es an den Konstruktor übergebe, mache ich einfach dies:

super(new InfoRunnable<ThingToPass>() {
    public ThingToPass run(Object... args) {
        /* do your things here */
    }
}.run(/* args here */));