Mais je ne veux pas changer affiche(), puisque le but de l'héritage est justement de réutiliser le code!
Oui mais là ce que tu veux c'est le polymorphisme, qui n'a rien à voir avec l'héritage, même si dans beaucoup de cas il s'obtient par héritage (mais pas dans tous, les langages plus faiblement typés comme Ruby sont des exceptions).
Bref, ton erreur est de confondre héritage et polymorphisme.
Par ailleurs, ce n'est pas le problème de la classe de base qui a gêné pour pwlib. C'est avec le nouveau code que les problèmes sont apparus: comme les classes de base n'avaient pas prévu d'être héritées, il a fallu flanquer des virtual dans tous les coins pour obtenir un truc qui marche correctement.
Ce qui est bien l'une des facettes du Fragile Base Class Problem, CQFD.
Tu aurais eu exactement le même pb en Java si, pour des raisons d'efficacité ou autre, l'auteur avait mis en 'final' certaines méthodes, et qu'après coup on découvre qu'on voudrait bien pouvoir les overrider quand même. Les deux sont des cas d'école, avec l'expérience tu apprends à te méfier, mais ça arrive toujours de se planter.
Apparemment il fallait connaître les futurs besoins avant de les avoir...
Bienvenue dans la dure réalité du design logiciel.
Ce que j'essaie d'expliquer depuis le début, c'est que la normalité quand on veut faire de l'héritage [...]
Ce que tu cherches à expliquer depuis le début manifestement sans bien comprendre les concepts derrière c'est qu'il est plus commode d'avoir des méthodes virtuelles par défaut. Et bien sur c'est vrai. Mais ça n'est pas sans inconvénients non plus (ça peut avoir un impact sur les perfs, mais moins grands qu'on le croit en général), et dans le cas de C++ ça n'était pas possible pour pouvoir garder la compatibilité avec C.
Ensuite, bien que ça aide pour faire des classes facilement réutilisables, ça ne résoud absolument pas tous les problèmes liés à l'héritage. Dès que tu dérives une classe tu crées un lien extrèmement fort entre ton code et la classe dérivée, et même en Java, il n'y a pas de miracles, tu te retrouves souvent à devoir hacker le code dont tu hérites (quand c'est possible).
Donc si tu crois vraiment qu'un langage n'est OO que si les méthodes y sont virtuelles par défaut, tu n'as rien compris et tu ne soupçonnes même pas à quel point le design OO peut être complexe, ni quels sont les outils dont on dispose en la matière. L'héritage n'étant que l'un d'entre eux, et certainement pas le plus important.
Enfin, concernant le fait que les créateurs de langage soient des clowns: ça ne me semble pas si impossible que ça.
Effectivement, ça n'est pas impossible, mais si à ce stade de la discussion tu es toujours persuadé d'avoir bien tout compris à la POO, et donc d'avoir assez de recul pour juger si les mecs qui ont fait C# sont des bozos ou pas, alors je crois qu'il est inutile de poursuivre.
[^] # Re: Langage objet...
Posté par Guillaume Laurent . En réponse à la dépêche Les nouveautés de Qt 4. Évalué à 1.
Oui mais là ce que tu veux c'est le polymorphisme, qui n'a rien à voir avec l'héritage, même si dans beaucoup de cas il s'obtient par héritage (mais pas dans tous, les langages plus faiblement typés comme Ruby sont des exceptions).
Bref, ton erreur est de confondre héritage et polymorphisme.
Par ailleurs, ce n'est pas le problème de la classe de base qui a gêné pour pwlib. C'est avec le nouveau code que les problèmes sont apparus: comme les classes de base n'avaient pas prévu d'être héritées, il a fallu flanquer des virtual dans tous les coins pour obtenir un truc qui marche correctement.
Ce qui est bien l'une des facettes du Fragile Base Class Problem, CQFD.
Tu aurais eu exactement le même pb en Java si, pour des raisons d'efficacité ou autre, l'auteur avait mis en 'final' certaines méthodes, et qu'après coup on découvre qu'on voudrait bien pouvoir les overrider quand même. Les deux sont des cas d'école, avec l'expérience tu apprends à te méfier, mais ça arrive toujours de se planter.
Apparemment il fallait connaître les futurs besoins avant de les avoir...
Bienvenue dans la dure réalité du design logiciel.
Ce que j'essaie d'expliquer depuis le début, c'est que la normalité quand on veut faire de l'héritage [...]
Ce que tu cherches à expliquer depuis le début manifestement sans bien comprendre les concepts derrière c'est qu'il est plus commode d'avoir des méthodes virtuelles par défaut. Et bien sur c'est vrai. Mais ça n'est pas sans inconvénients non plus (ça peut avoir un impact sur les perfs, mais moins grands qu'on le croit en général), et dans le cas de C++ ça n'était pas possible pour pouvoir garder la compatibilité avec C.
Ensuite, bien que ça aide pour faire des classes facilement réutilisables, ça ne résoud absolument pas tous les problèmes liés à l'héritage. Dès que tu dérives une classe tu crées un lien extrèmement fort entre ton code et la classe dérivée, et même en Java, il n'y a pas de miracles, tu te retrouves souvent à devoir hacker le code dont tu hérites (quand c'est possible).
Donc si tu crois vraiment qu'un langage n'est OO que si les méthodes y sont virtuelles par défaut, tu n'as rien compris et tu ne soupçonnes même pas à quel point le design OO peut être complexe, ni quels sont les outils dont on dispose en la matière. L'héritage n'étant que l'un d'entre eux, et certainement pas le plus important.
Enfin, concernant le fait que les créateurs de langage soient des clowns: ça ne me semble pas si impossible que ça.
Effectivement, ça n'est pas impossible, mais si à ce stade de la discussion tu es toujours persuadé d'avoir bien tout compris à la POO, et donc d'avoir assez de recul pour juger si les mecs qui ont fait C# sont des bozos ou pas, alors je crois qu'il est inutile de poursuivre.