Citation:
Envoyé par
hegros
Et alors il y a probablement autant de probabilités de recourir à l'héritage multiple en C++ que de recourir à la méthode Equals de Object donc dans les faits d'utilisation cela est du pareil au même. Et lorsqu'il y a un recours à Equals ou à l'héritage multiple les impacts sont certainement plus graves avec l'héritage multiple qu'avec l'appel à un Equals.
Tu te focalise sur la fonction Equals parce que c'est l'exemple que j'ai utilisé pour justifier le problème d'une classe super object et que j'ai répondu à foison sur certaines remarque la concernant, mais le problème n'est pas seulement cette fonction: le problème, c'est le coté implicite de la chose, et le fait que tu te retrouves fatalement avec une relation entre des objets que tu n'as peut etre pas souhaitée, mais qui risque malgré tout de t'inciter à adopter des pratiques qui n'ont pas lieu d'être (dans un domaine particulier s'entend ;) )
Bref, tu as décidé de laisser l'arbre que j'ai désigné te cacher la foret, c'est ton droit, mais c'est un peu limite quand meme :D
Citation:
Bref, il suffit de regarder sur quoi est fondée la bibliothèque standard c++ pour se rendre compte qu'elle n'utilise pas plus que cela l'héritage multiple (pour ainsi dire elle ne doit même pas l'utiliser) et il suffit de regarder sur quoi est fondé le langage/framework Java pour se rendre compte qu'il n'utilise pas plus que cela le Equals de Object.
D'autant plus que tu parles de comparaison mais là tu compares des voitures et des pommes. En effet, l'héritage multiple c'est propre au langage alors que Equals dans Object n'est pas propre au langage mais à une bibliothèque.
Tu sembles n'avoir rien compris à ce que j'ai expliqué plus haut : ce n'est pas la fonction equals qui me pose problème, c'est la présence de Object, même si j'admets que, dans le cadre de java, il n'y avait sans doute pas moyen de faire autrement.
Cela n'empêche que c'est conceptuellement une erreur, et que je l'ai malgré tout expliqué à foison (meme si c'est en me basant sur une seule fonction de cette classe ;) )
Citation:
On doit comprendre alors que les concepteurs de la bibliothèque standard du C++ (et probablement Qt et compagnie) ne se sont pas sentis de taille pour affronter ces problèmes mais que malgré tout tu en vantes les mérites invisibles dans les faits.
Tu te trompes:
1- La non utilisation d'une pratique autorisé veut simplement dire qu'elle n'est pas utile dans un contexte donné, mais qu'elle peut s'avérer particulièrement utile dans d'autres
2- Qt (parce que tu parles de ce framework) a, à mon sens, été beaucoup trop loin avec sa notion de QObject... Cependant, a contrario de java, il y a des pans entier de classes Qt qui ne sont pas QObject
3- (pour en terminer avec Qt) le développement de Qt a, selon moi, été entrepris quelques années trop tot, à une époque où nombre de compilateurs ne respectaient pas suffisamment la norme, ce qui les a poussé à souffrir du NIH... Elle traine depuis certains choix de conception qui, l'évolution des pratiques aidant, n'auraient sans doute pas été choisi quelques années plus tard (ce qui n'enlève rien à la qualité de la bibliothèque que j'utilise au quotidien ;))
Citation:
Et ne me sort pas l'exemple de la mouette qui est un oiseau et un dinosaure en même temps ou ce genre de choses car les cas où l'héritage multiple peut et se mets en pratique avec avantage doivent se compter sur les doigts d'une patte de crocodile :)
Combien de fois utilises tu le mot clé implements dans un projet java :question:
On déborde très certainement du modèle OO, mais, C++ permettant la généricité (d'une manière non comparable à celle de java), l'héritage multiple peut s'utiliser dans de nombreux cas sur des classes template ;)
Citation:
Non d'un point de vue des piliers de la conception il n'y a rien de horrible et de dangereux. Equals dans une classe Object respecte les Graps pattern et ce sont eux qui sont les fondements de la conception et dont dérive tous les autres patterns et conceptions, LSP n'y échappe pas.
Comme je l'ai dit plus haut, la fonction Equals n'est qu'un symptome du problème...
Le problème c'est que l'on te dit "tout est Object", ce n'est pas faux, mais le problème c'est que, LSP aidant, cela signifie que tu peux passer n'importe quel type là où un Object est attendu, mais, et c'est là le problème, en étant limité à l'interface de Object.
Cela implique qu'il te faudra trouver le moyen de retrouver, d'une manière ou d'une autre, l'interface qui te permettra de gérer ton argument de manière correcte, et donc, du transtypage "a foison" (ou des techniques de dispatch multiple).
Object (ou toute classe de base unique dans n'importe quel langage ou n'importe quel framework) presente donc une granularité beaucoup trop fine qui mène, à des pratiques qui auraient très bien pu être évitées s'il avait été absent, et qui, de ce fait, auraient entre autre augmenté la maintenabilité et limité les besoins de debuggage!
Citation:
C'est une mauvaise utilisation tout autant que l'est l'héritage multiple qui peut poser des problèmes de conception d'un autre ordre.
C'est ce que j'ai dit depuis le début pour l'un comme pour l'autre.
Le fait est que tu restes toujours libre de ne pas utiliser l'héritage multiple, mais tu est obligé de passer par l'héritage (direct ou indirect) de la classe Object!
Mais bon, je ne fais que répéter ce que j'ai dit plus tot, là ;)
Citation:
Bref, en C++ aussi il y a des éléments horribles et affreux (quoique ces mots sont à relativiser) :
-l'héritage multiple
j'en ai assez parlé pour que tu comprennes mon point de vue sur le sujet, là ;)
Citation:
-les constructeurs par recopie
Je te signale, en passant, que les constructeurs par recopie font simplement partie de la forme canonique de Coplien ;)
Citation:
-l'ordre des appels des constructeurs et destructeurs lorsque des mots clefs comme virtual s'appliquent sur de l'héritage (multiple ou pas)
L'héritage virtuel est une solution à un problème de conception à la base.
Si l'héritage multiple est déjà "relativement rare", les cas où (la conception étant bien faite par ailleurs) l'héritage virtuel est d'application le sont encore plus ;)
Citation:
-les variables globales
Ce n'est pas pour rien qu'on déconseille leur utilisation à longueur d'années...
C'est malheureusement un besoin indispensable pour assurer la compatibilité avec C :aie:
Le jour où il n'y aura plus de variables globales en C, elles disparaitront de facto en C++ ;)
Citation:
-la complexité inutile du langage et la pauvreté de son framework std rendant toute productivité, réactivité et maintenance à moindre coût impossible
C'est, à ma connaissance, le seul langage réellement multi paradigme qui n'essaye pas d'atteindre cet objectif en en "greffant" un sur l'autre...
J'admet sans problème que cela rend le langage plus complexe à aborder dans son ensemble ;)
Citation:
-sa disparité et son mauvais enseignement dans les écoles
Il est de moins en moins disparate (le support de la norme par les versions actuelles de compilateurs est de plus en plus bon).
Son mauvais enseignement dans les écoles vient, essentiellement, du fait que l'on a beaucoup trop tendance à dire au prof de C "bah, tu connais C, tu vas donner cours de C++"...
Sauf que 90% des pratiques fréquentes en C sont largement déconseillées en C++ ;)
Il faut, quand meme, éviter de rendre C++ responsable de ce qu'il n'est pas: demande à un incompétent en java de donner cours java, tu obtiendras des incompétents ;)
Citation:
-la vitesse quasi-nulle d'évolution du langage (cela va aussi vite que la norme html5 c'est pour dire...)
j'ai, effectivement, pesté contre la lenteur avec laquelle la nouvelle norme a été mise au point, maiis c'est beaucoup plus du au fait que cela passe par ISO qu'autre chose (C n'évolue plus aussi vite actuellement qu'à ses tout début non plus, pour les mêmes raisons, d'ailleurs ;))
Citation:
-la non évolutivité de la bibliothèque standard (il a dû fallu attendre 10 ans pour ajouter des threads....)
Même origines, mêmes conséquences...
Mais on les a, maintenant ;)
Citation:
-la non existence de sucres syntaxiques (tout le monde adopte aujourd'hui à minima les properties par exemple)
Ils existent, ils sont déconseillés, à juste titre, pour faciliter la relecture, tout simplement ;)
Citation:
-aucune innovation dans les concepts et les pratiques de la programmation (ou alors il faut attendre 15 ans)
Cela évolue sans doute bien plus que tu ne le crois de prime abord...
La manière d'envisager C++ actuelle n'a strictement rien à voir avec la manière dont il était envisagé quand il est apparu ;)
Regarde, en outre, les dates de parution de certains bouquins de niveau supérieur, et tu verras que cela a vraiment évolué pas mal;)
Citation:
-il faut recompiler ses sources pour chaque plateforme cible (autant dire que si ce n'est pas penser dés le départ et même quand c'est pensé dés le départ c'est plus que fastidieux)
Là, je suis d'accord...
Mais C ou la JVM doit aussi être recompilé(e) en fonction de la plateforme cible ;)
Citation:
Cela relativise plus qu'un peu une méthode Equals dans une classe Object :)
encore une fois, Equals n'est que le symptôme de ce que je soutiens...
Mais, si tu as décidé de croire que je n'en ai qu'à la fonction Equals, la discussion ne mènera nulle part ;)