Bonjour, j'ai trouvé cette définition du polymorphisme sur le web et ça
correspond exactement à l'idée que je m'en faisais :
"Le polymorphisme est le fait qu'un message identique envoye à
deux objets de classes differentes mais heritant d'une meme
superclasse puisse entrainer un traitement different de ce
message."
Dans mon cas, lors d'un projet il y a quelques mois j'avais un truc du
genre (ici version ultra simplifiée) :
classe object3D
classe staticObject dérivant de object3D
classe animatedObject dérivant de staticObject
classe character dérivant de object3D
classe player dérivant de character
dans object3D deux méthodes majeures étaient définies :
- update
- draw
et overloadées (surchargées) dans chaque classe dérivées.
ensuite, j'avais une classe scene dont un membre était un vector
d'object3D
Sauf que je créais des instances des classes dérivées et que je stockais
des pointeurs vers ces instances dans le vector en question.
Du coup, les méthodes update et draw appellée étaient correctes.
Ca semble bien correspondre à la définition ci-dessus et me semblait un
moyen très naturel de résoudre un certain nombre de problèmes (mais ce
n'est pas le propos).
Donc, je synthétise ma demande :
1) la définition ci-dessus est-elle juste ?
2) l'exemple que je fournis (le mien) est-il correct ?
Je dois rencontrer quelques profs de fac en vue de mon incarcération en
milieu technique, alors je voudrais pas bafouiller une énormité ;-)
Et pitié... Faites pas dans le détail !!!! Je sais qu'il y a ici des
intervenants très pointus sur le sujet... N'en faites pas trop hein !?
| La surcharge est un "sucre syntaxique" juste là pour simplifier la vie du | développeur
vu comme cela, qu'est-ce qui n'est pas du sucre syntaxique ?
-- Gaby
Alain Naigeon
"Gabriel Dos Reis" a écrit dans le message news: Luc Hermitte writes:
| La surcharge est un "sucre syntaxique" juste là pour simplifier la vie du | développeur
vu comme cela, qu'est-ce qui n'est pas du sucre syntaxique ?
Dans un autre fil, il a bien été dit que C++ est un sucre syntaxique de l'assembleur - j'exagère juste un peu ;-)
--
Français *==> "Musique renaissance" <==* English midi - facsimiles - ligatures - mensuration http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/ Alain Naigeon - - Strasbourg, France
"Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message
news: m3n0dehmn1.fsf@uniton.integrable-solutions.net...
Luc Hermitte <hermitte@free.fr.invalid> writes:
| La surcharge est un "sucre syntaxique" juste là pour simplifier la vie du
| développeur
vu comme cela, qu'est-ce qui n'est pas du sucre syntaxique ?
Dans un autre fil, il a bien été dit que C++ est un sucre
syntaxique de l'assembleur - j'exagère juste un peu ;-)
--
Français *==> "Musique renaissance" <==* English
midi - facsimiles - ligatures - mensuration
http://anaigeon.free.fr | http://www.medieval.org/emfaq/anaigeon/
Alain Naigeon - anaigeon@free.fr - Strasbourg, France
"Gabriel Dos Reis" a écrit dans le message de news:
mais le design, c'est du sucre syntaxique sur le programme :-/
Avec un peu de sel sémantique, qui plus est ;)
Chris
Gabriel Dos Reis
"Christophe Lephay" writes:
| "Gabriel Dos Reis" a écrit dans le message de | news: | > mais le design, c'est du sucre syntaxique sur le programme :-/ | | Avec un peu de sel sémantique, qui plus est ;)
le programe a une sémantique, c'est le design qui serait un sucre syntaxique sur cette sémantique.
| "Gabriel Dos Reis" <gdr@integrable-solutions.net> a écrit dans le message de
| news:m3ad9ehj14.fsf@uniton.integrable-solutions.net...
| > mais le design, c'est du sucre syntaxique sur le programme :-/
|
| Avec un peu de sel sémantique, qui plus est ;)
le programe a une sémantique, c'est le design qui serait un sucre
syntaxique sur cette sémantique.
| "Gabriel Dos Reis" a écrit dans le message de | news: | > mais le design, c'est du sucre syntaxique sur le programme :-/ | | Avec un peu de sel sémantique, qui plus est ;)
le programe a une sémantique, c'est le design qui serait un sucre syntaxique sur cette sémantique.
-- Gaby
Zouplaz
Luc Hermitte - :
Dans ton exemple, je suis quasi-persud que tu parles en fait de la _redfinition_ (overriding) (et non pas de la surcharge!) de mthodes dfinies dans une classe mre. Ici, cela concerne directement le design de ton application car tu dis qu'il est possible que l o un Objet3D est attendu, tu fourniras peut-tre bien un StaticObject dont la mthode Draw() aura t spcialise. [1]
Tu as tout à fait raison ! Il s'agit bien de redéfinition et non pas de surcharge !!
Et dire que c'est du "syntaxic sugar" était déjà affirmé dans les plus vieilles faq que j'ai pu lire il y a 10 ans.
Merci pour la précision
Luc Hermitte - hermitte@free.fr.invalid :
Dans ton exemple, je suis quasi-persud que tu parles en fait de la
_redfinition_ (overriding) (et non pas de la surcharge!) de mthodes
dfinies dans une classe mre.
Ici, cela concerne directement le design de ton application car tu dis
qu'il est possible que l o un Objet3D est attendu, tu fourniras
peut-tre bien un StaticObject dont la mthode Draw() aura t
spcialise. [1]
Tu as tout à fait raison ! Il s'agit bien de redéfinition et non pas de
surcharge !!
Et dire que c'est du "syntaxic sugar" était déjà affirmé dans les plus
vieilles faq que j'ai pu lire il y a 10 ans.
Dans ton exemple, je suis quasi-persud que tu parles en fait de la _redfinition_ (overriding) (et non pas de la surcharge!) de mthodes dfinies dans une classe mre. Ici, cela concerne directement le design de ton application car tu dis qu'il est possible que l o un Objet3D est attendu, tu fourniras peut-tre bien un StaticObject dont la mthode Draw() aura t spcialise. [1]
Tu as tout à fait raison ! Il s'agit bien de redéfinition et non pas de surcharge !!
Et dire que c'est du "syntaxic sugar" était déjà affirmé dans les plus vieilles faq que j'ai pu lire il y a 10 ans.
Merci pour la précision
kanze
Zouplaz wrote in message news:...
Bonjour, j'ai trouvé cette définition du polymorphisme sur le web et ça correspond exactement à l'idée que je m'en faisais :
"Le polymorphisme est le fait qu'un message identique envoye à deux objets de classes differentes mais heritant d'une meme superclasse puisse entrainer un traitement different de ce message."
Elle a l'air un peu confus. D'abord, il parle de « message », qui fait penser à Smalltalk. Mais en Smalltalk, pas besoin d'avoir une classe de base en commun ; en Smalltalk, il n'y a pas de vérificatin de type statique, et lors de la reception d'un message, on ne vérifie que l'existance d'un méthode pour traiter ce message.
En général, je crois qu'une bonne définition de polymorphisme doit être indépendante du langage, et même du fait que le typage soit statique (à la C++) ou non (à la Smalltalk). Or, l'héritage n'y joue un rôle que dans le cas du typage statique, où on hérite surtout des interfaces.
En fait, le polymorphisme, c'est simplement le fait de pouvoir envoyer un message identique, ou appeler la même fonction (la terminologie dépend du langage), sur des objets dont le type varie, dont on ne connaît pas forcement le type, et dont les types ont des implémentations différentes de la fonction. Le polymorphisme peuvent se résoudre lors de la compilation, lors de l'édition de liens, ou lors de l'exécution -- lors qu'il se résoud lors de l'exécution, on parle souvent de la programmation orientée objet.
Dans mon cas, lors d'un projet il y a quelques mois j'avais un truc du genre (ici version ultra simplifiée) :
classe object3D classe staticObject dérivant de object3D classe animatedObject dérivant de staticObject classe character dérivant de object3D classe player dérivant de character
dans object3D deux méthodes majeures étaient définies : - update - draw
et overloadées (surchargées) dans chaque classe dérivées.
Pas overloaded/surchargées. Overridden/rédéfinies
Sinon, c'est l'exemple classique du polymorphisme dynamique, c-à-d résolution lors de l'exécution. La nécessité d'une classe Object3D, dans ce cas, est due au typage statique de C++ ; dans Smalltalk, si les classes de base ne comportaient pas d'implémentation dont tu voulais héritée, elle ne serait pas nécessaire.
ensuite, j'avais une classe scene dont un membre était un vector d'object3D Sauf que je créais des instances des classes dérivées et que je stockais des pointeurs vers ces instances dans le vector en question.
Du coup, les méthodes update et draw appellée étaient correctes.
Ca semble bien correspondre à la définition ci-dessus et me semblait un moyen très naturel de résoudre un certain nombre de problèmes (mais ce n'est pas le propos).
Donc, je synthétise ma demande : 1) la définition ci-dessus est-elle juste ?
Je la trouve un peu confu, mais elle va dans le bon sens.
2) l'exemple que je fournis (le mien) est-il correct ?
Tout à fait. C'est même l'exemple type.
Je dois rencontrer quelques profs de fac en vue de mon incarcération en milieu technique, alors je voudrais pas bafouiller une énormité ;-)
Et pitié... Faites pas dans le détail !!!! Je sais qu'il y a ici des intervenants très pointus sur le sujet... N'en faites pas trop hein !?
Si on veut ignorer les détails, je dirais simplement : - que la définition donnée ne concerne réelement que le polymorphisme dynamique, lors de l'exécution, et qu'il en existe d'autres, et - que la nécessité d'héritage dans le polymorphisme, c'est un artifact du typage statique.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Zouplaz <pouet@pouet.com> wrote in message
news:<Xns93F0DE8EE5B25Zoupla@213.228.0.75>...
Bonjour, j'ai trouvé cette définition du polymorphisme sur le web et
ça correspond exactement à l'idée que je m'en faisais :
"Le polymorphisme est le fait qu'un message identique envoye à deux
objets de classes differentes mais heritant d'une meme superclasse
puisse entrainer un traitement different de ce message."
Elle a l'air un peu confus. D'abord, il parle de « message », qui fait
penser à Smalltalk. Mais en Smalltalk, pas besoin d'avoir une classe de
base en commun ; en Smalltalk, il n'y a pas de vérificatin de type
statique, et lors de la reception d'un message, on ne vérifie que
l'existance d'un méthode pour traiter ce message.
En général, je crois qu'une bonne définition de polymorphisme doit être
indépendante du langage, et même du fait que le typage soit statique (à
la C++) ou non (à la Smalltalk). Or, l'héritage n'y joue un rôle que
dans le cas du typage statique, où on hérite surtout des interfaces.
En fait, le polymorphisme, c'est simplement le fait de pouvoir envoyer
un message identique, ou appeler la même fonction (la terminologie
dépend du langage), sur des objets dont le type varie, dont on ne
connaît pas forcement le type, et dont les types ont des implémentations
différentes de la fonction. Le polymorphisme peuvent se résoudre lors de
la compilation, lors de l'édition de liens, ou lors de l'exécution --
lors qu'il se résoud lors de l'exécution, on parle souvent de la
programmation orientée objet.
Dans mon cas, lors d'un projet il y a quelques mois j'avais un truc du
genre (ici version ultra simplifiée) :
classe object3D
classe staticObject dérivant de object3D
classe animatedObject dérivant de staticObject
classe character dérivant de object3D
classe player dérivant de character
dans object3D deux méthodes majeures étaient définies :
- update
- draw
et overloadées (surchargées) dans chaque classe dérivées.
Pas overloaded/surchargées. Overridden/rédéfinies
Sinon, c'est l'exemple classique du polymorphisme dynamique, c-à-d
résolution lors de l'exécution. La nécessité d'une classe Object3D, dans
ce cas, est due au typage statique de C++ ; dans Smalltalk, si les
classes de base ne comportaient pas d'implémentation dont tu voulais
héritée, elle ne serait pas nécessaire.
ensuite, j'avais une classe scene dont un membre était un vector
d'object3D Sauf que je créais des instances des classes dérivées et
que je stockais des pointeurs vers ces instances dans le vector en
question.
Du coup, les méthodes update et draw appellée étaient correctes.
Ca semble bien correspondre à la définition ci-dessus et me semblait
un moyen très naturel de résoudre un certain nombre de problèmes (mais
ce n'est pas le propos).
Donc, je synthétise ma demande :
1) la définition ci-dessus est-elle juste ?
Je la trouve un peu confu, mais elle va dans le bon sens.
2) l'exemple que je fournis (le mien) est-il correct ?
Tout à fait. C'est même l'exemple type.
Je dois rencontrer quelques profs de fac en vue de mon incarcération
en milieu technique, alors je voudrais pas bafouiller une énormité ;-)
Et pitié... Faites pas dans le détail !!!! Je sais qu'il y a ici des
intervenants très pointus sur le sujet... N'en faites pas trop hein !?
Si on veut ignorer les détails, je dirais simplement :
- que la définition donnée ne concerne réelement que le polymorphisme
dynamique, lors de l'exécution, et qu'il en existe d'autres, et
- que la nécessité d'héritage dans le polymorphisme, c'est un artifact
du typage statique.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Bonjour, j'ai trouvé cette définition du polymorphisme sur le web et ça correspond exactement à l'idée que je m'en faisais :
"Le polymorphisme est le fait qu'un message identique envoye à deux objets de classes differentes mais heritant d'une meme superclasse puisse entrainer un traitement different de ce message."
Elle a l'air un peu confus. D'abord, il parle de « message », qui fait penser à Smalltalk. Mais en Smalltalk, pas besoin d'avoir une classe de base en commun ; en Smalltalk, il n'y a pas de vérificatin de type statique, et lors de la reception d'un message, on ne vérifie que l'existance d'un méthode pour traiter ce message.
En général, je crois qu'une bonne définition de polymorphisme doit être indépendante du langage, et même du fait que le typage soit statique (à la C++) ou non (à la Smalltalk). Or, l'héritage n'y joue un rôle que dans le cas du typage statique, où on hérite surtout des interfaces.
En fait, le polymorphisme, c'est simplement le fait de pouvoir envoyer un message identique, ou appeler la même fonction (la terminologie dépend du langage), sur des objets dont le type varie, dont on ne connaît pas forcement le type, et dont les types ont des implémentations différentes de la fonction. Le polymorphisme peuvent se résoudre lors de la compilation, lors de l'édition de liens, ou lors de l'exécution -- lors qu'il se résoud lors de l'exécution, on parle souvent de la programmation orientée objet.
Dans mon cas, lors d'un projet il y a quelques mois j'avais un truc du genre (ici version ultra simplifiée) :
classe object3D classe staticObject dérivant de object3D classe animatedObject dérivant de staticObject classe character dérivant de object3D classe player dérivant de character
dans object3D deux méthodes majeures étaient définies : - update - draw
et overloadées (surchargées) dans chaque classe dérivées.
Pas overloaded/surchargées. Overridden/rédéfinies
Sinon, c'est l'exemple classique du polymorphisme dynamique, c-à-d résolution lors de l'exécution. La nécessité d'une classe Object3D, dans ce cas, est due au typage statique de C++ ; dans Smalltalk, si les classes de base ne comportaient pas d'implémentation dont tu voulais héritée, elle ne serait pas nécessaire.
ensuite, j'avais une classe scene dont un membre était un vector d'object3D Sauf que je créais des instances des classes dérivées et que je stockais des pointeurs vers ces instances dans le vector en question.
Du coup, les méthodes update et draw appellée étaient correctes.
Ca semble bien correspondre à la définition ci-dessus et me semblait un moyen très naturel de résoudre un certain nombre de problèmes (mais ce n'est pas le propos).
Donc, je synthétise ma demande : 1) la définition ci-dessus est-elle juste ?
Je la trouve un peu confu, mais elle va dans le bon sens.
2) l'exemple que je fournis (le mien) est-il correct ?
Tout à fait. C'est même l'exemple type.
Je dois rencontrer quelques profs de fac en vue de mon incarcération en milieu technique, alors je voudrais pas bafouiller une énormité ;-)
Et pitié... Faites pas dans le détail !!!! Je sais qu'il y a ici des intervenants très pointus sur le sujet... N'en faites pas trop hein !?
Si on veut ignorer les détails, je dirais simplement : - que la définition donnée ne concerne réelement que le polymorphisme dynamique, lors de l'exécution, et qu'il en existe d'autres, et - que la nécessité d'héritage dans le polymorphisme, c'est un artifact du typage statique.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Luc Hermitte
drkm wrote in news::
Je t'épargne les détails, au pire on a des références sous le coude.
On veut des noms !
cf la réponse de Gabriel à James. Il y a un article dispo en ligne qui donne des définitions pour le polymorphisme -- google doit pouvoir retrouver l'adresse que j'ai encore paumée.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
drkm <darkman_spam@yahoo.fr> wrote in news:wkllsymjfc.fsf@yahoo.fr:
Je t'épargne les détails, au pire on a des références sous le coude.
On veut des noms !
cf la réponse de Gabriel à James. Il y a un article dispo en ligne qui
donne des définitions pour le polymorphisme -- google doit pouvoir
retrouver l'adresse que j'ai encore paumée.
--
Luc Hermitte <hermitte at free.fr>
FAQ de <news:fr.comp.lang.c++> :
<http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/>
Dejanews : <http://groups.google.com/advanced_group_search>
Je t'épargne les détails, au pire on a des références sous le coude.
On veut des noms !
cf la réponse de Gabriel à James. Il y a un article dispo en ligne qui donne des définitions pour le polymorphisme -- google doit pouvoir retrouver l'adresse que j'ai encore paumée.
-- Luc Hermitte <hermitte at free.fr> FAQ de <news:fr.comp.lang.c++> : <http://www.cmla.ens-cachan.fr/Utilisateurs/dosreis/C++/FAQ/> Dejanews : <http://groups.google.com/advanced_group_search>
