Question sur le typage dynamique en Java

Question

je suis arrivé ce à partir d'une diffusion sur le Web des structures de données Berkley cs:

class A { 
    void f() {System.out.println("A.f");} 
    void g() {f();} 
// static void g(A y) {y.f();} 
} 

class B extends A { 
    void f(){ 
    System.out.println("B.f"); 
    } 
} 

class C { 
    static void main (String[] args){ 
    B aB = new B(); 
    h (aB); 
    } 

    static void h (A x) {x.g();} 
    //static void h (A x) {A.g(x);} what if this were h 

} 

Pouvez-vous me dire ce qui imprime et pourquoi? L'instructeur a dit B.f mais je ne comprends pas pourquoi. Je pensais que c'était A.f. Merci (non, je ne suis pas dans la classe, j'essaie juste d'apprendre.)

edit: désolé pour les erreurs que je copiais à partir d'une conférence vidéo.

Answer 1

La raison pour laquelle "B.f" imprime est que l'implémentation d'une méthode est déterminée par le type d'exécution d'un objet, et non par son type de compilation. C'est comme le mot-clé virtual en C++.

Une fois que vous construisez un B, vous savez que l'appel de sa méthode f imprimera « B.f », même si le B est fait référence comme A.

En outre, votre méthode A.f manque un accolade étroite.

Answer 2

ce code n'est pas correct, A.g() ne prend aucun argument.

static void h (A x) {A.g(x);} 

A.g (x); essaie d'appeler une méthode statique sur A appelée g avec x comme argument. Cela n'est pas possible avec l'exemple de code que vous avez publié.

autre que le code incorrect, la raison est B remplace la méthode f() avec sa propre implémentation. Ainsi, toutes les instances de B telles que B x = new B(); appellera le f() que B ne définit pas le A.f(). La seule façon d'atteindre le A.f() serait de l'intérieur d'une instance de B en appelant super.f();

Answer 3

Cet exemple illustre la puissance de la programmation orientée objet. Comme ab est une instance de B, tout appel de méthode sur ab utilisera les fonctions définies dans B, même si ces fonctions sont appelées indirectement via une fonction définie dans une superclasse.

L'exemple est si abstrait que la vertu de ceci peut ne pas être claire. Permettez-moi un exemple un peu plus réaliste:

class Employee 
{ 
    ... bunch of stuff ... 
    void calcPay() 
    { 
    pay=hoursWorked*hourlyRate; 
    } 
    void produceCheck)) 
    { 
    calcPay(); 
    calcTaxes(); 
    calcBenefitDeductions(); 
    printCheck(); 
    } 
} 
class Salesman extends Employee 
{ 
    void calcPay() 
    { 
    pay=sales*commissionRate; 
    } 
} 
... somewhere else ... 
for (Employee employee1 : employeeList) 
{ 
    employee1.produceCheck(); 
} 

Je laisse toutes sortes de détails pour faire le point: Ce code ne compilera pas.

Mais voici le point: vendeur ont une méthode différente de calcul de leur salaire, puis les autres employés: Ils sont payés à la commission au lieu de l'heure. (Dans la vraie vie, nous aurions probablement aussi des employés, mais comme je le dis, je simplifie.) La fonction de calcul du salaire de l'un ou l'autre type d'employé est appelée à partir d'une fonction plus importante. La beauté de la programmation orientée objet est que nous pouvons appeler la fonction extérieure et ne pas nous soucier de savoir si l'objet contre lequel nous l'appelons est un employé régulier ou un vendeur. Chaque objet sait ce que c'est et appelle la bonne fonction. Dans les dernières lignes de l'exemple, nous avons une structure qui inclut à la fois les employés réguliers et les vendeurs, et nous pouvons les parcourir et les traiter sans avoir à vérifier leur type. Sans POO, nous aurions à écrire constamment du code comme: "if (type == SALESMAN) ... else if (type == HOURLY) ..."