Pourquoi la délégation à un constructeur différent doit-elle se produire en premier dans un constructeur Java?

Je pense que plusieurs des réponses ici sont fausses car elles supposent que l'encapsulation est en quelque sorte cassée lors de l'appel de super() après avoir invoqué du code. Le fait est que le super peut réellement casser l'encapsulation elle-même, car Java permet de surcharger les méthodes dans le constructeur.

Considérez ces classes:

class A {
  protected int i;
  public void print() { System.out.println("Hello"); }
  public A() { i = 13; print(); }
}

class B extends A {
  private String msg;
  public void print() { System.out.println(msg); }
  public B(String msg) { super(); this.msg = msg; }
}

Si vous le faites

new B("Wubba lubba dub dub");

Le message imprimé est "null". C'est parce que le constructeur de A accède au champ non initialisé de B. donc franchement semble que si quelqu'un voulait faire ceci:

class C extends A {
  public C() { 
    System.out.println(i); // i not yet initialized
    super();
  }
} 

Alors c'est tout autant leur problème que s'ils font la Classe B ci-dessus. Dans les deux cas, le programmeur doit savoir comment les variables sont accessibles pendant la construction. Et étant donné que vous pouvez appeler super() ou this() avec toutes sortes d'expressions dans la liste des paramètres, cela semble être une restriction artificielle que vous ne pouvez pas calculer d'expressions avant d'appeler l'autre constructeur. Sans oublier que la restriction s'applique aux deux super() et {[4] } quand vous savez probablement comment ne pas casser votre propre encapsulation en appelant this().

Mon verdict: cette fonctionnalité est un bug dans le compilateur, peut-être à l'origine motivé par une bonne raison, mais dans sa forme actuelle c'est une limitation artificielle sans but.

Les constructeurs doivent être appelés dans l'ordre, de la classe parent racine à la classe la plus dérivée. Vous ne pouvez pas exécuter de code au préalable dans le constructeur dérivé car avant l'appel du constructeur parent, le cadre de pile du constructeur dérivé n'a même pas encore été alloué, car le constructeur dérivé n'a pas commencé à s'exécuter. Certes, la syntaxe pour Java ne rend pas ce fait clair.

Edit: pour résumer, quand un constructeur de classe dérivé "s'exécute" avant le présent appel, les points suivants s'appliquent.

1. les variables membres ne peuvent pas être touchées, car elles ne sont pas valides avant la base les classes sont construites.
2. les Arguments sont en lecture seule, car le cadre de la pile n'a pas été alloué.
3. les variables locales ne sont pas accessibles, car le cadre de la pile n'a pas été alloué.

Vous pouvez accéder aux arguments et aux variables locales si vous avez alloué les trames de pile des constructeurs dans l'ordre inverse, des classes dérivées à classes de base, mais cela nécessiterait que toutes les images soient actives en même temps, gaspillant de la mémoire pour chaque construction d'objet pour permettre le cas rare de code qui veut toucher les variables locales avant que les classes de base soient construites.

" ma conjecture est que, jusqu'à ce qu'un constructeur ait été appelé pour chaque niveau de la heierarchy, l'objet est dans un état invalide. Il est dangereux pour la JVM d'exécuter quoi que ce soit sur elle jusqu'à ce qu'elle ait été complètement construite."

En fait, il est possible de construire des objets en Java sans appeler tous les constructeurs de la hiérarchie, mais pas avec le mot clé new.

Par exemple, lorsque la sérialisation de Java construit un objet pendant désérialisation, il appelle le constructeur de la première classe non sérialisable dans la hiérarchie. Ainsi, lorsque java.util.HashMap est désérialisé, d'abord un java.util.L'instance HashMap est allouée, puis le constructeur de sa première superclasse java non sérialisable.util.AbstractMap est appelé (qui à son tour appelle java.lang.Constructeur de l'objet).

Vous pouvez également utiliser la bibliothèque Objenesis pour instancier des objets sans appeler le constructeur.

, Ou si vous êtes si incliné, vous peut générer le bytecode vous-même (avec ASM ou similaire). Au niveau du bytecode, new Foo() compile deux instructions:

NEW Foo
INVOKESPECIAL Foo.<init> ()V

, Si vous voulez éviter d'appeler le constructeur de Foo, vous pouvez modifier la deuxième commande, par exemple:

NEW Foo
INVOKESPECIAL java/lang/Object.<init> ()V

Mais même alors, le constructeur de Foo doit contenir un appel à sa superclasse. Sinon, le chargeur de classe de la JVM lancera une exception lors du chargement de la classe, se plaignant qu'il n'y a pas d'appel à super().

Permettre au code de ne pas appeler le super constructeur casse d'abord l'encapsulation - l'idée que vous pouvez écrire du code et pouvoir prouver que peu importe ce que fait quelqu'un d'autre - l'étendre, l'invoquer, l'instancier - il sera toujours dans un état valide.

IOW: ce n'est pas une exigence JVM en tant que telle, mais une exigence Comp Sci. Et important.

Pour résoudre votre problème, incidemment, vous utilisez des méthodes statiques privées - elles ne dépendent d'aucune exemple:

public BigFraction(BigDecimal d)
{
  this(appropriateInitializationNumeratorFor(d),
       appropriateInitializationDenominatorFor(d));
}

private static appropriateInitializationNumeratorFor(BigDecimal d)
{
  if(d.scale() < 0)
  {
    return d.unscaledValue().multiply(BigInteger.TEN.pow(-d.scale()));
  }
  else
  {
    return d.unscaledValue();
  }
}

Si vous n'aimez pas avoir des méthodes séparées (beaucoup de logique commune que vous ne voulez exécuter qu'une seule fois, par exemple), ayez une méthode qui renvoie une petite classe interne statique privée qui est utilisée pour appeler un constructeur privé.

Mon guess est que, jusqu'à ce qu'un constructeur ait été appelé pour chaque niveau de la heierarchy, l'objet est dans un état invalide. Il est dangereux pour la JVM d'exécuter quoi que ce soit sur elle jusqu'à ce qu'elle ait été complètement construite.

Eh bien, le problème est que java ne peut pas détecter les 'instructions' que vous allez mettre avant le super appel. Par exemple, vous pouvez vous référer à des variables membres qui ne sont pas encore initialisées. Donc, je ne pense pas que java supportera jamais cela. Maintenant, il existe de nombreuses façons de contourner ce problème, par exemple en utilisant des méthodes d'usine ou de modèle.

Regarde par là.

Disons qu'un objet est composé de 10 pièces.

1,2,3,4,5,6,7,8,9,10

Ok?

De 1 à 9 sont dans la super classe, partie # 10 est votre ajout.

Simple ne peut pas ajouter la 10e partie tant que les 9 précédentes ne sont pas terminées.

C'est ça.

Si de 1-6 proviennent d'une autre super classe aussi bien, la chose est qu'un seul objet est créé dans une séquence spécifique, c'est la façon dont est conçu.

Sur bien sûr, la vraie raison est beaucoup plus complexe que cela, mais je pense que cela répondrait à peu près à la question.

En ce qui concerne les alternatives, je pense qu'il y a beaucoup déjà posté ici.