Discussion :

[mathk]

bonjour,

Une petite devinette pour les amoureux des types:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
class A
     public foo(Z z)
         print  "a.foo"
 
class B extend A
 
    public foo(Y y)
         print "b.foo"

Y herite de Z

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 B b = new B()
 A a = new A()
 
 A bA = b
 
 bA.foo(y)
 bA.foo(z)

Donc quelqu'un sias t'il quel est le resultat des 2 dernieres instructions (sans utiliser de VM)?

Quelqu'un sais t'il l'expliquer?

[eclesia]

Z et Y sont des classes inconnues qui n'ont aucune incidence sur le code présenté.

la procédure foo n'est pas un constructeur et pas de d'appelle a la fonction parente vu qu'il n'y a pas de "super()"

bA même s'il est traité comme un objet de classe A est toujours un objet de classe B, donc pour "bA.foo(y)" on utilise la methode de la classe B.

alors je dirais pour ca :
bA.foo(y)
bA.foo(z)

donne :
b.foob.foo


non?

[mathk]

Non
D'autre tentative.

Z et Y ont une influance

[djo.mos]

Logiquement, le résultat devrait être :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
b.foo
a.foo

explication :
bA.foo(y) est en fait B.foo car sa signature correspond.
bA.foo(z) est en fait A.foo car sa signature correspond, malgré le fait que bA soit instancié avec B mais Java garde toujours trace de toute l'hiérarchie des méthodes redéfinies.

mais c'est faux ! j'ai essayé ce bout de code sur la JVM 6.0 et c'est pas le bon résultat !
J'ai beau me creuser les méninges, je n'arrive pas à trouver l'explication ... ça remet en cause les fondements du mécanisme des méthodes virtuelles de Java ...
Voilou ! C'est un méchant méchant piège mathk !

[adiGuba]

Salut,

ça remet en cause les fondements du mécanisme des méthodes virtuelles de Java ...

Non : Les deux méthodes n'ont pas la même signature ! Il n'y a donc pas d'héritage.

Comme c'est dit dans le titre il s'agit overloading (surcharge) et non pas d'overriding (redéfinition) : il s'agit donc de deux méthodes distinctes qui n'ont pas de lien de parenté, ce qui n'implique pas de mécanisme d'héritage...

D'ailleurs on peut bien voir cela avec Java 5.0 et + en utilisant l'annotation @Overrides sur foo(Y), qui génèrera une erreur car justement elle ne redéfinit pas une méthode parente...


En fait c'est comme si on avait deux méthodes avec des noms différents : fooY() et fooZ(), sauf que c'est le compilateur qui gère cette différence selon le type des paramètres...


Donc lorsque le compilateur voit le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 bA.foo(y)
 bA.foo(z)

Il recherche les méthodes à appelées, et là on a deux cas distinct :

• Les classes Y et Z n'ont aucun lien de parenté, et le compilateur émettra une erreur car la classe A ne définit aucune méthode foo(Y) (ou "compatible").
• La classe Y hérite de Z, et dans ce cas le compilateur effectuera un appel de la méthode foo(Z) en lui passant une instance de Y.

a++

[deltree]

Je ne saurais mieux dire
Cet exemple met simplement en évidence la différence fondamentale entre surcharge et redéfinition en Java.

Il y a plusieurs moyen de se rappeler simplement l'impact d'une surcharge:
-"La surcharge est résolue à la compilation": donc c'est le type déclaré de la variable qui permet de retrouver la méthode appelée et non pas le type de l'objet au Runtime. (donc comme si c'était 2 méhode différentes)

-"La redéfinition est résolue à l'exécution (au Runtime)": c'est la base du mécanisme du polymorphisme, et des avantages de l'objet.

La leçon à retenir de l'exercice, c'est que lorsqu'on veut du polymorphisme, il faut bien passer par une redéfinition (et donc bien choisir la signature de la méthode à surcharger) et jamais par une surcharge.

Il y a un moyen d'être quand même polymorphe avec une surcharge, en les faisant toutes au niveau de la classe de base, et en testant les instanceOf mais comme tous les moyens détournés, c'est fortement déconseillé, mieux vaut utiliser le polymorphisme Java tel qu'il est prévu et en accepter les règles AMHA.

[mathk]

Ok donc petite question subsidiaires:

b.m(z)
a.m(y)

[bassim]

si le résultat n'est pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
b.foo
a.foo

alors c'est quoi ??

[adiGuba]

si le résultat n'est pas :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
b.foo
a.foo

alors c'est quoi ??

Seul la méthode foo(Z) peut être appelé, donc le résultat est forcément :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
a.foo
a.foo

Et cela implique que x et z soit des types compatibles avec Z.


Sinon cela provoquera un erreur de compilation.


Le pseudo-code est trompeur et manque de précision...

a++

[mathk]

Le pseudo-code est trompeur et manque de précision...

Quel tromperie

Une petite conclusion a cela. Avant de passer au veritable problemes
En Java le type statique influance l'execution.

[pseudocode]

Quel tromperie

Une petite conclusion a cela. Avant de passer au veritable problemes
En Java le type statique influance l'execution.

Moi, je dirais surtout comme deltree:

"c'est le type déclaré de la variable qui permet de retrouver la méthode appelée"

Ou, en plus simple: Lorsqu'une instance est "castée" en interface, seules les methodes de l'interface sont accessibles.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 B b = new B()
 A a = new A()
 
 A bA = b
 
 bA.foo(y)
 bA.foo(z)

comme "ba" est de type "A", les appels "ba.foo(...)" appeleront toujours "A.foo(...)".

(Seule exception a la regle: l'overriding.)

[mathk]

"c'est le type déclaré de la variable qui permet de retrouver la méthode appelée"

Oui typer déclaré = type statique