Polymorphisme en JAVA

Version imprimable

Bonjour à tous,

J'ai un peu de mal à comprendre le polymorphisme dans JAVA... Comment il fonctionne et comment JAVA le comprends et le compile puis l’exécute.

Voici mon code:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 public class A { public String f(D obj) { return "AD"; } public String f(A obj) { return "AA"; } } public class B extends A { public String f(B obj) { return "BB"; } public String f(A obj) { return "BA"; } } public class C extends B { } public class D extends B{ } public class tr { public static void main(String[] args) { A a1= new A(); A a2=new B(); B b= new B(); C c= new C(); D d= new D(); System.out.println(a1.f(b)); System.out.println(a1.f(c)); System.out.println(a1.f(d)); System.out.println(a2.f(b)); System.out.println(a2.f(c)); System.out.println(a2.f(d)); System.out.println(b.f(b)); System.out.println(b.f(c)); System.out.println(b.f(d)); } }
J'obtiens l'affichage suivant:
AA // ici je comprends
AA // idem
AD // idem
BA // je ne comprends pas l'affichage ici, si je suis le principe de la résolution dynamique comment je le comprends, j'obtiens BB.. Vu que a2 a comme type effectif: B. Donc pour moi on a un truc du genre "Object B.f(Object B)".. Je ne comprends vraiment pas la technique...
BA // ici je ne comprends pas non plus
AD // ici non plus
BB
BB
AD

Si quelqu'un peut m'expliquer sa technique je suis preneur...

Merci d'avance,
Cordialement,
Tootun

15/12/2017, 20h11
thelvin
Hello,

peut-être que ça aiderait de bien faire la différence entre ce qui se passe au moment de la compilation, et ce qui se passe au moment de l'exécution.

Comme son nom l'indique, ce qui est dynamique, c'est à l'exécution. Là, on est en train de manipuler des vrais objets en live, et l'implémentation de leurs comportement peut dépendre de quelle est leur classe réelle maintenant qu'on est bel et bien en train de les exécuter et qu'on les a sous la main pour connaître leur classe.

Par contre, tout ce qui se passe à la compilation, pendant qu'on est en train d'écrire le programme, ça c'est entièrement statique. Pendant la compilation, le programmeur sait peut-être, parce qu'il le déduit en lisant le programme, quelles seront les classes réelles des objets manipulés. Mais le compilateur, lui, n'en sait rien. Il n'a pas les objets disponibles pour vérifier leur type comme ce sera le cas à l'exécution.

Or, il faut bien comprendre que choisir quels champs on va lire/écrire, choisir quelle méthode on appelle, tout cela, c'est fait à la compilation. C'est statique.
Ce qui est dynamique, et qui peut dépendre des types réels, c'est quelle est l'implémentation réelle que fournit l'objet pour la méthode qu'on a décidé d'appeler. Certes les méthodes ont déjà été décidées à la compilation... Mais les sous-classes peuvent décider de redéfinir leurs méthodes : ce sont toujours les mêmes qu'on a décidé d'appeler, mais leur comportement est différent.

Tu dis que pour a2.f(b) => BA, tu ne comprends pas. Tu te dis que l'objet B sur lequel on appelle une méthode f(), ça devrait être sa méthode f(B), puisque le paramètre b est de type B.
Oui mais, quelle méthode est appelée, c'est décidé à la compilation. C'est à dire à un moment où on ne connaît pas les types réels des objets. Or l'objet a2 semble peut-être évidemment de type B, mais ça, ça ne sera connu qu'à l'exécution. À la compilation, il est déclaré comme ça :

Code:

A a2 = quelque chose qui sera évalué à l'exécution;

Imagine que B ne définisse pas de méthode f(B) mais à la place une méthode
Code:

1 2 3 public String toto() { return "toto"; }
Tu crois vraiment que tu pourrais appeler a2.toto() ?

Eh ben non, puisque a2 est une variable de type A, et que la classe A n'a pas de méthode toto() que tu pourrais possiblement appeler.

C'est pareil. La classe A n'a pas non plus de méthode f(B). Elle a une méthode f(A) et une méthode f(D), donc c'est l'une des deux qui peut être appelée. Elle n'a pas de méthode f(B), et donc cette méthode qui n'existe pas ne sera pas appelée.
Celle qui est choisie n'est pas f(D) car le paramètre, b, est de type B qui n'est pas un sous-type de D.
Par contre, le type B est un sous-type de A, donc rien ne s'oppose à choisir la méthode f(A), ce qui est donc fait.
La compilation est faite, c'est décidé, c'est la méthode f(A) qui est appelée avec ce code.

Ensuite, à l'exécution, il se trouve que l'objet contenu dans la variable a2, est un objet de classe B. Et la classe B redéfinit la méthode f(A), celle qu'on a choisi d'appeler. C'est donc la méthode f(A) de la classe B qui est exécutée.

Même raisonnement pour les autres : la méthode qui sera appelée, ça se choisit à la compilation. L'implémentation de cette méthode par les objets sur lesquelles on l'appelle, ça dépend de quelle implémentation ces objets fournissent à l'exécution, du fait de leur classe réelle.
16/12/2017, 00h39
tchize_
Il faut savoir que le compilateur, il va utiliser les signatures des méthodes, pas seulement leur nom. Il va parcourir toutes les méthode et construire un appel qu'il stockera dans la jvm. Ensuite, à l'exécution, la JVM va appeler la méthode ayant cette signature, mais sur l'instance réelle. Décomposons ton code comme le vois le compilateur. Je vais utiliser une notation sans parenthèse pour bien distinguer le code de la classe compilée
Code:

1 2 3 4 5 6 Classe A méthode f__D méthode f__A Classe B (extends A) méthode f__B méthode f__A
Ton code:
Code:

1 2 3 4 A a2; C c; a2.f(c));
le compilateur analyse a2 et c.
a2 est de type A.
Il doit donc trouver une méthode f dans A. Au choix: f__D f__A
c est de type C. Il n'y a pas de méthode f__C. Par contre il ya bien une f__A qui est compatible.

Le code compilé deviens donc

a2.f__A(c)

A l'exécution maintenant. La jvm a une instance a2 qui contient un B. Elle va donc chercher f__A dans B qu'elle trouve et va l'appeler.

Deuxième cas.
Code:

1 2 3 4 A a2; D d; a2.f(d));
le compilateur analyse a2 et d.
a2 est de type A.
Il doit donc trouver une méthode f dans A. Au choix: f__D f__A
d est de type D. Il y a bien une f__D qui est compatible.

Le code compilé deviens donc

a2.f__D(d)

A l'exécution maintenant. La jvm a une instance a2 qui contient un B. Elle va donc chercher f__D dans B qu'elle ne trouve pas. Elle va alors inspecter le parent A, va trouver ce f__D et l'appeler.