héritage et membres classe

Question

DONNÉ:

class A 
{ 
    String s = "A"; 
} 

class B extends A 
{ 
    String s = "B"; 
} 

public class C 
{ 
    public static void main(String[] args){ new C().go();} 
    void go() 
    { 
     A a = new B(); 
     System.out.println(a.s); 
    } 
} 

Question:

Quels sont les mécanismes derrière JVM lorsque ce code est exécuté? Comment se fait-il que a.s s'imprime en "A".

Answer 1

références sur le terrain ne sont pas soumis à un polymorphisme, donc au moment de la compilation le compilateur fait référence le champ A parce que votre variable locale est de type A.

En d'autres termes, le comportement sur le terrain est comme le comportement de surcharge Java sur les méthodes , pas le comportement de substitution de Java.

Answer 2

Ce n'est pas un polymorphisme (comme marqué).

Java a virtual methods, et non variables de membre virtuel - c'est-à-dire que vous ne remplacez pas une propriété - vous la cachez.

Answer 3

Vous vous attendez probablement à ce que des champs soient remplacés comme une méthode, avec une répartition dynamique basée sur le type d'exécution de l'objet.

Ce n'est pas comme cela que fonctionne Java. Les champs ne sont pas écrasés, ils sont cachés. Cela signifie qu'un objet de la classe B a deux champs nommés "s", mais lequel d'entre eux est accessible dépend du contexte. Pour ce qui est de la raison: il ne serait pas vraiment utile de surcharger les champs, car il n'y a aucun moyen utile de le faire fonctionner quand les types sont différents, et simplement aucun point quand le type est le même (comme vous pouvez simplement utiliser le champ superclasse). Personnellement, je pense que ce devrait simplement être une erreur de compilateur.

Answer 4

Bien que les variables membres soient héritées d'une classe de base, elles ne sont pas appelées de façon polymorphe (l'appel dynamique ne s'applique pas aux variables membres). Ainsi, a.s se référera au membre de la classe de base et non à la classe dérivée. Cela dit, le code ne suit pas les principes OO. Les membres d'une classe doivent être privés/protégés (non public ou par défaut) en fonction du cas d'utilisation de l'entreprise et vous devez fournir des méthodes publiques pour obtenir et définir les valeurs du membre.