j'ai un objet, disons "o", qui peut-être soit une String soit une Map,
je ne connais pas la méthode la plus élégante, disons la pus "javaish"
pour tester la classe de cette objet, ce que je fais et qui marche :
j'ai un autre objet "on" qui est toujours une String je fais donc :
String onClass = on.getClass().toString();
par ailleurs :
String oClass = o.getClass().toString();
puis je teste sans pb:
if (onClass.equals(oClass) {
faire ce qu'il faut dans ce cas là...
}
j'ai essayé, sans succès :
if ("java.lang.String".equals(oClass) {...
l'égalité n'est jamais trouvée... ce que je ne comprend pas.
d'où ma question, donc si vous avez des lumières à m'apporter, j'en
serai ravi et vous remercie d'avance...
On Tue, 12 Oct 2004 14:25:19 +0200, Laurent Bossavit wrote:
Un exemple de code objet va souvent contenir plusieurs techniques.
Oui, je m'en suis rendu compte en relisant mon exemple.
L'appel à Animal.crie() dans le second exemple est bien un appel poymorphique, puisqu'il peut, à l'exécution, se traduire par l'appel de deux implémentations différentes.
m.nourrir(medor); // appelle la première méthode m.nourrir(minou); // appelle la deuxième méthode
Oui. On parle de deux types de polymorphisme distincts: moi du polymorphisme d'objet, et ci-dessus, du polymorphisme par surcharge.
OK, on peut appeller les choses comme ça. J'aime bien cette terminologie (polymorphisme d'objet / polymorphisme par surcharge), comme ça, pas de confusion possible.
Attention: en Java, les règles de ce dernier sont beaucoup moins claires que celles concernant les appels de méthodes sur un objet.
Mmmm, j'en suis pas convaincu.
Que ce soit avec le polymorphisme d'objet medor.crie(); minou.crie(); ou avec le polymorphisme par surcharge maitre.nourrir(medor); maitre.nourrir(minou); il faut savoir que le polymorphisme existe pour se rendre compte que les méthodes appellées ne sont pas les mêmes. Les deux mécanismes me semblent aussi (peu) lisibles l'un que l'autre.
Deux remarques cependant: 1- les règles pour déterminer la méthode à appeler sont différentes pour les deux types de polymorphisme (à l'exécution/à la compilation). Aucune des deux règles ne me semble plus claire que l'autre, c'est juste une question de choix. (par contre, c'est vrai que d'avoir des règles différentes peut déstabiliser les débutants) 2- j'ai cru remarquer chez les programmeurs OO un biais assez fort vers l'héritage au détriment d'autres techniques OO. Ca expliquerait la préférence pour le polymorphisme d'objet.
En espérant me faire comprendre, parce que j'ai du mal à trouver les mots justes. -- Thomas
On Tue, 12 Oct 2004 14:25:19 +0200, Laurent Bossavit wrote:
Un exemple de code objet va souvent contenir plusieurs techniques.
Oui, je m'en suis rendu compte en relisant mon exemple.
L'appel à Animal.crie() dans le second exemple est bien un appel
poymorphique, puisqu'il peut, à l'exécution, se traduire par l'appel de
deux implémentations différentes.
m.nourrir(medor); // appelle la première méthode
m.nourrir(minou); // appelle la deuxième méthode
Oui. On parle de deux types de polymorphisme distincts: moi du
polymorphisme d'objet, et ci-dessus, du polymorphisme par surcharge.
OK, on peut appeller les choses comme ça. J'aime bien cette terminologie
(polymorphisme d'objet / polymorphisme par surcharge), comme ça, pas de
confusion possible.
Attention: en Java, les règles de ce dernier sont beaucoup moins
claires que celles concernant les appels de méthodes sur un objet.
Mmmm, j'en suis pas convaincu.
Que ce soit avec le polymorphisme d'objet
medor.crie(); minou.crie();
ou avec le polymorphisme par surcharge
maitre.nourrir(medor); maitre.nourrir(minou);
il faut savoir que le polymorphisme existe pour se
rendre compte que les méthodes appellées ne sont pas les mêmes.
Les deux mécanismes me semblent aussi (peu) lisibles l'un que l'autre.
Deux remarques cependant:
1- les règles pour déterminer la méthode à appeler sont différentes
pour les deux types de polymorphisme (à l'exécution/à la compilation).
Aucune des deux règles ne me semble plus claire que l'autre, c'est juste
une question de choix. (par contre, c'est vrai que d'avoir des règles
différentes peut déstabiliser les débutants)
2- j'ai cru remarquer chez les programmeurs OO un biais assez fort vers
l'héritage au détriment d'autres techniques OO. Ca expliquerait la
préférence pour le polymorphisme d'objet.
En espérant me faire comprendre, parce que j'ai du mal à trouver les
mots justes.
-- Thomas
On Tue, 12 Oct 2004 14:25:19 +0200, Laurent Bossavit wrote:
Un exemple de code objet va souvent contenir plusieurs techniques.
Oui, je m'en suis rendu compte en relisant mon exemple.
L'appel à Animal.crie() dans le second exemple est bien un appel poymorphique, puisqu'il peut, à l'exécution, se traduire par l'appel de deux implémentations différentes.
m.nourrir(medor); // appelle la première méthode m.nourrir(minou); // appelle la deuxième méthode
Oui. On parle de deux types de polymorphisme distincts: moi du polymorphisme d'objet, et ci-dessus, du polymorphisme par surcharge.
OK, on peut appeller les choses comme ça. J'aime bien cette terminologie (polymorphisme d'objet / polymorphisme par surcharge), comme ça, pas de confusion possible.
Attention: en Java, les règles de ce dernier sont beaucoup moins claires que celles concernant les appels de méthodes sur un objet.
Mmmm, j'en suis pas convaincu.
Que ce soit avec le polymorphisme d'objet medor.crie(); minou.crie(); ou avec le polymorphisme par surcharge maitre.nourrir(medor); maitre.nourrir(minou); il faut savoir que le polymorphisme existe pour se rendre compte que les méthodes appellées ne sont pas les mêmes. Les deux mécanismes me semblent aussi (peu) lisibles l'un que l'autre.
Deux remarques cependant: 1- les règles pour déterminer la méthode à appeler sont différentes pour les deux types de polymorphisme (à l'exécution/à la compilation). Aucune des deux règles ne me semble plus claire que l'autre, c'est juste une question de choix. (par contre, c'est vrai que d'avoir des règles différentes peut déstabiliser les débutants) 2- j'ai cru remarquer chez les programmeurs OO un biais assez fort vers l'héritage au détriment d'autres techniques OO. Ca expliquerait la préférence pour le polymorphisme d'objet.
En espérant me faire comprendre, parce que j'ai du mal à trouver les mots justes. -- Thomas
Laurent Bossavit
Thomas,
Attention: en Java, les règles de ce dernier sont beaucoup moins claires que celles concernant les appels de méthodes sur un objet.
Mmmm, j'en suis pas convaincu.
Imaginons l'exemple suivant:
public class Maitre public void nourrir(Animal unAnimal) System.out.println("Donne de la patée générique à "+unAnimal); public void nourrir(Chien unChien) System.out.println("Donne de la patée pour chien à "+unAnimal);
// Code client... Animal monCopain; monCopain = new Chat(); maitre.nourrir(monCopain);
monCopain = new Chien(); maitre.nourrir(monCopain);
2- j'ai cru remarquer chez les programmeurs OO un biais assez fort vers l'héritage au détriment d'autres techniques OO.
C'est exact, et je n'approuve pas de ce biais pour l'héritage. Mais le polymorphisme est parfaitement possible sans héritage. Mon premier exemple n'utilisait pas l'héritage...
1- les règles pour déterminer la méthode à appeler sont différentes pour les deux types de polymorphisme (à l'exécution/à la compilation).
C'est spécifique à Java et sa "famille": il existe des langages objets (dits "à multiméthodes") qui peuvent résoudre /à l'exécution/ un appel polymorphique en fonction de tous les arguments. Java et Smalltalk ne gèrent correctement, c'est-à-dire à l'exécution, que le polymorphisme sur l'objet "cible" du message.
C'est la résolution à l'exécution qui est la plus intéressante, puisqu'elle permet le maximum de généricité. Dans mon exemple ci-dessus, Java n'est pas fichu de donner à un chien de la patée pour chien !
Laurent http://bossavit.com/thoughts/
Thomas,
Attention: en Java, les règles de ce dernier sont beaucoup moins
claires que celles concernant les appels de méthodes sur un objet.
Mmmm, j'en suis pas convaincu.
Imaginons l'exemple suivant:
public class Maitre
public void nourrir(Animal unAnimal)
System.out.println("Donne de la patée générique à "+unAnimal);
public void nourrir(Chien unChien)
System.out.println("Donne de la patée pour chien à "+unAnimal);
// Code client...
Animal monCopain;
monCopain = new Chat();
maitre.nourrir(monCopain);
monCopain = new Chien();
maitre.nourrir(monCopain);
2- j'ai cru remarquer chez les programmeurs OO un biais assez fort vers
l'héritage au détriment d'autres techniques OO.
C'est exact, et je n'approuve pas de ce biais pour l'héritage. Mais le
polymorphisme est parfaitement possible sans héritage. Mon premier
exemple n'utilisait pas l'héritage...
1- les règles pour déterminer la méthode à appeler sont différentes
pour les deux types de polymorphisme (à l'exécution/à la compilation).
C'est spécifique à Java et sa "famille": il existe des langages objets
(dits "à multiméthodes") qui peuvent résoudre /à l'exécution/ un appel
polymorphique en fonction de tous les arguments. Java et Smalltalk ne
gèrent correctement, c'est-à-dire à l'exécution, que le polymorphisme
sur l'objet "cible" du message.
C'est la résolution à l'exécution qui est la plus intéressante,
puisqu'elle permet le maximum de généricité. Dans mon exemple ci-dessus,
Java n'est pas fichu de donner à un chien de la patée pour chien !
Attention: en Java, les règles de ce dernier sont beaucoup moins claires que celles concernant les appels de méthodes sur un objet.
Mmmm, j'en suis pas convaincu.
Imaginons l'exemple suivant:
public class Maitre public void nourrir(Animal unAnimal) System.out.println("Donne de la patée générique à "+unAnimal); public void nourrir(Chien unChien) System.out.println("Donne de la patée pour chien à "+unAnimal);
// Code client... Animal monCopain; monCopain = new Chat(); maitre.nourrir(monCopain);
monCopain = new Chien(); maitre.nourrir(monCopain);
2- j'ai cru remarquer chez les programmeurs OO un biais assez fort vers l'héritage au détriment d'autres techniques OO.
C'est exact, et je n'approuve pas de ce biais pour l'héritage. Mais le polymorphisme est parfaitement possible sans héritage. Mon premier exemple n'utilisait pas l'héritage...
1- les règles pour déterminer la méthode à appeler sont différentes pour les deux types de polymorphisme (à l'exécution/à la compilation).
C'est spécifique à Java et sa "famille": il existe des langages objets (dits "à multiméthodes") qui peuvent résoudre /à l'exécution/ un appel polymorphique en fonction de tous les arguments. Java et Smalltalk ne gèrent correctement, c'est-à-dire à l'exécution, que le polymorphisme sur l'objet "cible" du message.
C'est la résolution à l'exécution qui est la plus intéressante, puisqu'elle permet le maximum de généricité. Dans mon exemple ci-dessus, Java n'est pas fichu de donner à un chien de la patée pour chien !
Laurent http://bossavit.com/thoughts/
no.bcausse.spam
Laurent Bossavit wrote:
Imaginons l'exemple suivant:
public class Maitre public void nourrir(Animal unAnimal) System.out.println("Donne de la patée générique à "+unAnimal); public void nourrir(Chien unChien) System.out.println("Donne de la patée pour chien à "+unAnimal);
// Code client... Animal monCopain; monCopain = new Chat(); maitre.nourrir(monCopain);
monCopain = new Chien(); maitre.nourrir(monCopain);
public class Maitre
public void nourrir(Animal unAnimal)
System.out.println("Donne de la patée générique à "+unAnimal);
public void nourrir(Chien unChien)
System.out.println("Donne de la patée pour chien à "+unAnimal);
// Code client...
Animal monCopain;
monCopain = new Chat();
maitre.nourrir(monCopain);
monCopain = new Chien();
maitre.nourrir(monCopain);
public class Maitre public void nourrir(Animal unAnimal) System.out.println("Donne de la patée générique à "+unAnimal); public void nourrir(Chien unChien) System.out.println("Donne de la patée pour chien à "+unAnimal);
// Code client... Animal monCopain; monCopain = new Chat(); maitre.nourrir(monCopain);
monCopain = new Chien(); maitre.nourrir(monCopain);
je tenterai 1, 2(l'animal est un chien, le runtime doit le savoir), 2 -- bruno Causse http://perso.wanadoo.fr/othello
Laurent Bossavit
Bruno,
Quels appels à nourrir() sont polymorphiques ? bonne question quelle est la reponse?
je tenterai 1, 2(l'animal est un chien, le runtime doit le savoir), 2
Hélas non... Seulement le dernier, parce qu'on a "aidé" le compilo: en passant une référence de type Chien, il va sélectionner la méthode qui prend Chien en paramètre. Les deux premiers appels sont aiguillés sur la méthode générique.
Laurent
Bruno,
Quels appels à nourrir() sont polymorphiques ?
bonne question quelle est la reponse?
je tenterai 1, 2(l'animal est un chien, le runtime doit le savoir), 2
Hélas non... Seulement le dernier, parce qu'on a "aidé" le compilo: en
passant une référence de type Chien, il va sélectionner la méthode qui
prend Chien en paramètre. Les deux premiers appels sont aiguillés sur la
méthode générique.
Quels appels à nourrir() sont polymorphiques ? bonne question quelle est la reponse?
je tenterai 1, 2(l'animal est un chien, le runtime doit le savoir), 2
Hélas non... Seulement le dernier, parce qu'on a "aidé" le compilo: en passant une référence de type Chien, il va sélectionner la méthode qui prend Chien en paramètre. Les deux premiers appels sont aiguillés sur la méthode générique.
Laurent
Thomas Nguyen
On Tue, 12 Oct 2004 18:17:20 +0200, Laurent Bossavit wrote:
1- les règles pour déterminer la méthode à appeler sont différentes pour les deux types de polymorphisme (à l'exécution/à la compilation).
C'est spécifique à Java et sa "famille": il existe des langages objets (dits "à multiméthodes") qui peuvent résoudre /à l'exécution/ un appel polymorphique en fonction de tous les arguments. Java et Smalltalk ne gèrent correctement, c'est-à-dire à l'exécution, que le polymorphisme sur l'objet "cible" du message.
C'est la résolution à l'exécution qui est la plus intéressante, puisqu'elle permet le maximum de généricité.
Cet argument est très intéressant. Ca me convainc pas que la résolution à l'exécution soit "plus correcte" que la résolution à la compilation; mais le pouvoir d'expression me parait plus grand. (Tiens, encore un sujet pour des débats stériles et sans fin. Peut-être la prochaine flamewar? ;-P )
Tu as pas des exemples de langages qui font cette résolution à l'exécution? (juste pour ma culture générale, ça m'étonnerais que j'arrête Java juste pour ça)
Dans mon exemple ci-dessus, Java n'est pas fichu de donner à un chien de la patée pour chien !
C'est vrai que ton exemple met particulièrement bien en avant ce "défaut". ;) Ca aurait pas été aussi convaincant avec deux classes sans lien de parenté.
On Tue, 12 Oct 2004 18:17:20 +0200, Laurent Bossavit wrote:
1- les règles pour déterminer la méthode à appeler sont différentes
pour les deux types de polymorphisme (à l'exécution/à la compilation).
C'est spécifique à Java et sa "famille": il existe des langages objets
(dits "à multiméthodes") qui peuvent résoudre /à l'exécution/ un appel
polymorphique en fonction de tous les arguments. Java et Smalltalk ne
gèrent correctement, c'est-à-dire à l'exécution, que le polymorphisme
sur l'objet "cible" du message.
C'est la résolution à l'exécution qui est la plus intéressante,
puisqu'elle permet le maximum de généricité.
Cet argument est très intéressant. Ca me convainc pas que la résolution
à l'exécution soit "plus correcte" que la résolution à la compilation;
mais le pouvoir d'expression me parait plus grand. (Tiens, encore un sujet
pour des débats stériles et sans fin. Peut-être la prochaine flamewar?
;-P )
Tu as pas des exemples de langages qui font cette résolution à
l'exécution? (juste pour ma culture générale, ça m'étonnerais que
j'arrête Java juste pour ça)
Dans mon exemple ci-dessus,
Java n'est pas fichu de donner à un chien de la patée pour chien !
C'est vrai que ton exemple met particulièrement bien en avant ce
"défaut". ;)
Ca aurait pas été aussi convaincant avec deux classes sans lien de
parenté.
On Tue, 12 Oct 2004 18:17:20 +0200, Laurent Bossavit wrote:
1- les règles pour déterminer la méthode à appeler sont différentes pour les deux types de polymorphisme (à l'exécution/à la compilation).
C'est spécifique à Java et sa "famille": il existe des langages objets (dits "à multiméthodes") qui peuvent résoudre /à l'exécution/ un appel polymorphique en fonction de tous les arguments. Java et Smalltalk ne gèrent correctement, c'est-à-dire à l'exécution, que le polymorphisme sur l'objet "cible" du message.
C'est la résolution à l'exécution qui est la plus intéressante, puisqu'elle permet le maximum de généricité.
Cet argument est très intéressant. Ca me convainc pas que la résolution à l'exécution soit "plus correcte" que la résolution à la compilation; mais le pouvoir d'expression me parait plus grand. (Tiens, encore un sujet pour des débats stériles et sans fin. Peut-être la prochaine flamewar? ;-P )
Tu as pas des exemples de langages qui font cette résolution à l'exécution? (juste pour ma culture générale, ça m'étonnerais que j'arrête Java juste pour ça)
Dans mon exemple ci-dessus, Java n'est pas fichu de donner à un chien de la patée pour chien !
C'est vrai que ton exemple met particulièrement bien en avant ce "défaut". ;) Ca aurait pas été aussi convaincant avec deux classes sans lien de parenté.
Laurent Bossavit
Thomas,
Tu as pas des exemples de langages qui font cette résolution à l'exécution?
Le plus connu est sans doute Dylan: http://www.gwydiondylan.org/books/dpg/db_84.html
Il y a également quelques "Java++" : http://www.multijava.org/ http://nice.sourceforge.net/
Laurent http://bossavit.com/thoughts/
Thomas,
Tu as pas des exemples de langages qui font cette résolution à
l'exécution?
Le plus connu est sans doute Dylan:
http://www.gwydiondylan.org/books/dpg/db_84.html
Il y a également quelques "Java++" :
http://www.multijava.org/
http://nice.sourceforge.net/
Tu as pas des exemples de langages qui font cette résolution à l'exécution?
Le plus connu est sans doute Dylan: http://www.gwydiondylan.org/books/dpg/db_84.html
Il y a également quelques "Java++" : http://www.multijava.org/ http://nice.sourceforge.net/
Laurent http://bossavit.com/thoughts/
naopro-solutions
yvon.thoravalNO-SPAM a écrit le 11/10/2004 à 16h05 :
Bonjour,
j'ai un objet, disons "o", qui peut-être soit une String soit une Map, je ne connais pas la méthode la plus élégante, disons la pus "javaish" pour tester la classe de cette objet, ce que je fais et qui marche :
j'ai un autre objet "on" qui est toujours une String je fais donc :
String onClass = on.getClass().toString(); par ailleurs : String oClass = o.getClass().toString(); puis je teste sans pb:
if (onClass.equals(oClass) { faire ce qu'il faut dans ce cas là... }
j'ai essayé, sans succès :
if ("java.lang.String".equals(oClass) {...
l'égalité n'est jamais trouvée... ce que je ne comprend pas.
d'où ma question, donc si vous avez des lumières à m'apporter, j'en serai ravi et vous remercie d'avance...
-- yt
Bonjour,
essayes ceci
if (oClass.getClass().equals(java.lang.String.class)
Cordialement.
yvon.thoravalNO-SPAM a écrit le 11/10/2004 à 16h05 :
Bonjour,
j'ai un objet, disons "o", qui peut-être soit une String soit
une Map,
je ne connais pas la méthode la plus élégante, disons la
pus "javaish"
pour tester la classe de cette objet, ce que je fais et qui marche :
j'ai un autre objet "on" qui est toujours une String je fais donc :
String onClass = on.getClass().toString();
par ailleurs :
String oClass = o.getClass().toString();
puis je teste sans pb:
if (onClass.equals(oClass) {
faire ce qu'il faut dans ce cas là...
}
j'ai essayé, sans succès :
if ("java.lang.String".equals(oClass) {...
l'égalité n'est jamais trouvée... ce que je ne comprend
pas.
d'où ma question, donc si vous avez des lumières à
m'apporter, j'en
serai ravi et vous remercie d'avance...
--
yt
Bonjour,
essayes ceci
if (oClass.getClass().equals(java.lang.String.class)
yvon.thoravalNO-SPAM a écrit le 11/10/2004 à 16h05 :
Bonjour,
j'ai un objet, disons "o", qui peut-être soit une String soit une Map, je ne connais pas la méthode la plus élégante, disons la pus "javaish" pour tester la classe de cette objet, ce que je fais et qui marche :
j'ai un autre objet "on" qui est toujours une String je fais donc :
String onClass = on.getClass().toString(); par ailleurs : String oClass = o.getClass().toString(); puis je teste sans pb:
if (onClass.equals(oClass) { faire ce qu'il faut dans ce cas là... }
j'ai essayé, sans succès :
if ("java.lang.String".equals(oClass) {...
l'égalité n'est jamais trouvée... ce que je ne comprend pas.
d'où ma question, donc si vous avez des lumières à m'apporter, j'en serai ravi et vous remercie d'avance...
-- yt
Bonjour,
essayes ceci
if (oClass.getClass().equals(java.lang.String.class)
