Discussion :

[hegros]

A ceci près que tu restes libre de recourir à l'héritage multiple alors que l'héritage de la super classe objet est implicite!

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.


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.

Depuis quand on compare un langage à une bibliothèque ????????? Depuis quand on compare la conception d'un langage avec la conception d'une bibliothèque ???????

On te laisses donc le choix d'utiliser (ou non) l'héritage multiple si tu te sens de taille à affronter les problèmes qu'il peut poser

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.

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

De plus, je n'ai jamais dit que le recours à la super classe object n'était pas justifié, et j'admets une grande part des justifications qui pourront être données (ne les connaissant pas toutes, je me réserve juste le droit de n'être peut être pas d'accord avec toutes ).

Mais il n'empêche que, conceptuellement parlant, c'est un choix de conception horrible et dangereux (ou à tout le moins discutable) car il crée des relations forcées là où, a priori, il n'y a peut etre pas lieu d'en avoir (ne serait-ce que le fait de permettre qu'un caillou et qu'un véhicule puisse se retrouver dans une même collection d'objets, ou celui d'en arriver à admettre qu'il soit possible de trouver une relation d'équivalence entre l'un et l'autre, même si je suis convaincu que nous ne devrions pas parler d'équivalence mais bel et bien d'égalité au sujet de la fonction equals).

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.

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.

Bref, en C++ aussi il y a des éléments horribles et affreux (quoique ces mots sont à relativiser) :

-l'héritage multiple
-les constructeurs par recopie
-l'ordre des appels des constructeurs et destructeurs lorsque des mots clefs comme virtual s'appliquent sur de l'héritage (multiple ou pas)
-les variables globales
-la complexité inutile du langage et la pauvreté de son framework std rendant toute productivité, réactivité et maintenance à moindre coût impossible
-sa disparité et son mauvais enseignement dans les écoles
-la vitesse quasi-nulle d'évolution du langage (cela va aussi vite que la norme html5 c'est pour dire...)
-la non évolutivité de la bibliothèque standard (il a dû fallu attendre 10 ans pour ajouter des threads....)
-la non existence de sucres syntaxiques (tout le monde adopte aujourd'hui à minima les properties par exemple)
-aucune innovation dans les concepts et les pratiques de la programmation (ou alors il faut attendre 15 ans)
-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)

Cela relativise plus qu'un peu une méthode Equals dans une classe Object

[gl]

Les critères d'une comparaison sont purement ARBITRAIRES, le problème c'est que vous vous limitez à votre expérience personnelle de type de problème que avez eu à résoudre ou que vous imaginez possible de résoudre. Je peux décider qu'une voiture est égale à un cailloux si le poids du véhicule dépasse 100kg et celui du caillou inférieur à 5kg. Si dans votre expérience propre de la résolution des problèmes cela n'a aucun sens là n'est pas le problème. Le problème est que une foi admis cette règle comment par exemple écrire un programme qui va comparer une voiture et un cailloux donné et afficher vert s'il y a égalité et rouge sinon.

Tu viens de mettre indirectement le doigt sur ce qui me gênes le plus personnellement dans le concept de classe de base object :

• Si j'ai besoin de la fonctionnalité dans mon problème, c'est impeccable je l'ai par héritage.
• Si je n'en ai pas besoin, ben je l'ai aussi.

C'est ce côté "contaminant" (je trouve que ce terme à une connotation beaucoup trop négatif, mais je n'en trouve pas de meilleurs) qui ne m'emballe pas plus que ça. Ceci étant ce n'est pas non plus un problème catastrophique et c'est probablement en grande partie une opinion très subjective.

-l'héritage multiple

Préférerais-tu cette forme partielle d'héritage multiple qui ne permet pas le NVI, la validation des contrats, etc. que l'on appelle l'interface ?
Plus sérieusement, en comprenant et respectant le LSP ça ne pose pas tant de soucis que ça et permet de faire des interfaces infiniment plus riches que les interfaces Java.
Autant j'imagine assez bien comment se passer d'héritage multiple dans un langage comme D qui propose des interfaces un peu plus souples/riches que Java, le support de la PpC et autres mixin, autant je n'y arrive pas vraiment en Java.

-les constructeurs par recopie

Que reproches-tu précisément ?

-l'ordre des appels des constructeurs et destructeurs lorsque des mots clefs comme virtual s'appliquent sur de l'héritage (multiple ou pas)

Quel ordre aurais-tu voulu?

-la complexité inutile du langage et la pauvreté de son framework std rendant toute productivité, réactivité et maintenance à moindre coût impossible

Complexité peut-être.
Inutile, non je ne pense pas.

Quant à la "productivité, réactivité et maintenance à moindre coût impossible", vu que j'observe où je travaille et où il y a des projets en C++, en Java et dans d'autres langages, ça ne me semble pas aussi évident que ça (typiquement il y a un projet en Java qui pose de réels problèmes d'évolution et de maintenance, bien plus que les projets en C++ pour une complexité de même ordre de grandeur. Toutefois, je ne pense pas que ça vienne du langage, mais plutôt du framework utilisé et du manque de rigueur d'une partie de l'équipe).

-sa disparité et son mauvais enseignement dans les écoles

Certes. Mais le reprocher au langage est assez gonflé. Et l'herbe n'est pas plus verte ailleurs, loin de là.

-la vitesse quasi-nulle d'évolution du langage (cela va aussi vite que la norme html5 c'est pour dire...)

Ah ça, tout le monde aimerait que ça aille plus vite. C'est la conséquence d'une "gouvernance" par consensus de groupe aux intérêts divergents qui freine l'évolution par rapport à un langage où une entité (ou un groupe restreint) décide plus ou moins unilatéralement. Ça a aussi ces avantages.

-la non évolutivité de la bibliothèque standard (il a dû fallu attendre 10 ans pour ajouter des threads....)

C'est exactement le même point que le précédent.

-la non existence de sucres syntaxiques (tout le monde adopte aujourd'hui à minima les properties par exemple)

Si, il y a pas mal de sucre et, contrairement à d'autres langages, on peut rajouter le sien.
Il n'y a effectivement pas le supports des properties. D'un autre côté, je ne ressens pas ça comme un manque. Je ne vois pas le problème que les propriétés résolvent ni la simplification que cela apporte.

-aucune innovation dans les concepts et les pratiques de la programmation (ou alors il faut attendre 15 ans)

Peux-tu expliciter ce point ?
En particulier, puis-qu’ici on compare à Java, ce que Java a apporter de plus que C++ dans ce domaine (et on parle bien d'innovation apportée, pas de popularisation de pratiques/concepts existant).

-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)

Oui pour la recompilation (c'est la différence entre portabilité du code vs portabilité d'un byte code) et oui c'est une contrainte.
Par contre je ne vois pas en quoi, il faut y penser dès le départ ? Ce qu'il faut prévoir dès le départ, c'est la portabilité que l'on souhaite et donc le sous-ensemble utilisable dans ce contexte. Mais c'est vrai dans tout les cas pas uniquement en C++.


Quitte à parler des points noirs du C++, j'aurais plutôt cité :

• L'absence de certaines fonctionnalités en standard qui m'ont parfois manquée (GC, réflexivité, fonctionnel, etc.) même s'il existe bien souvent un support plus ou moins aboutit via une bibliothèque tierce, un contournement via de l'huile de coude et parfois une évolution dans le bon sens
• La partie de l'héritage C que le C++ se traine aujourd'hui comme un boulet (void*, header et non un vrai système de module - même si pour le coup le choix de Java me semble encore pire - trop nombreux casts implicites, etc.). Même si c'est probablement ce qui explique en partie que C++ ait percé.

[Luc Hermitte]

a- 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.
b- 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.


c- 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- 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.

e- 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.

f- -aucune innovation dans les concepts et les pratiques de la programmation (ou alors il faut attendre 15 ans)

a- equals est nécessaire en Java dès que l'on veut stocker dans des containers et faire des recherches de présence.
b- Il y a toute une littérature sur equals (qui a certes fini par converger) sur comment s'en servir correctement vis-à-vis des problèmes de double-dispatch/perte des types originaux évoqués par Koala.
Grave ? Probablement pas ? Propre ? Certainement pas. L'alternative ? J'y reviens plus bas.

L'héritage multiple ? Pareil, il y a une littérature à ce sujet -> le LSP. 1- comprendre le LSP et l'héritage simple, 2- appliquer à l'héritage multiple (vu que c'est pareil). 3- La programmation par contrat appliquées à de multiples interface. (certes Eiffel a été meilleur sur ce sujet -- comme bien d'autres, à se demander pourquoi ce fut C++ puis Java qui ont eu le vent en poupe...)

Le problème est un problème d'enseignement. Tant que l'on persistera à vouloir faire croire que l'héritage apporte la réutilisation de code, nous ne serons pas prêt d'avancer sur le sujet. Remarque on fait déjà n'importe quoi à enseigner setters (et getters) comme un artifact de la POO (et par extension les propriétés), alors qu'il s'agit d'un viol caractérisé de la loi de Déméter (et de principes fondamentaux de la POO: abstraction et encapsulation).
Je m'égare.

c- La lib standard du C++ STL n'est tout simplement pas orientée objet.
Je suis tombé cette semaine sur une vielle (2002) video de Stepanov qui est fort intéressante. Il critique un certains nombre de choses dont le polymorphisme mono-argument des langages mainstream.
[ame="http://video.google.com/videoplay?docid=-7867514878945314586"]Alexander Stepanov: STL and Its Design Principles[/ame]
La video est fort sympa, et parle assez peu de C++ (pour sa longueur)


d- Non equals est obligatoire dans le langage Java parce qu'il a fait le choix de ne pas disposer du polymorphisme paramétrique pour être rapidement (et au bon moment) sur le marché. Avec un typage affaibli, et l'absence de polymorphisme d'inclusion sur plusieurs arguments, il devient alors nécessaire de recourir à ce vilain hack pour supporter des recherches dans des conteneurs.

Avant 98, il y avait des alternatives à la STL, qui je n'en serais pas surpris devaient exploiter des hacks dans le même esprit. Abandonnées car on a pu faire plus carré avec le système de typage du C++. Avec le recul, on sait que l'on aurait pu faire encore mieux (cf les ranges, ou certains choix du D).


e- conteneurs + equals est juste totalement bancal. Il y a deux choix pour l'implémenter, et celui en poupe aujourd'hui est juste le moins pire des deux.

f- hum ... Il suffit juste de suivre boost (et même ACE avant dans la famille réseau et MT) pour voir le genre d'innovations qui sont sorties.
Certes le langage permettait déjà tout cela en 98, mais il a fallu du temps pour découvrir jusqu'au on pouvait le pousser, pour apercevoir les limites enfin de proposer mieux aujourd'hui.

[hegros]

Tu viens de mettre indirectement le doigt sur ce qui me gênes le plus personnellement dans le concept de classe de base object :

• Si j'ai besoin de la fonctionnalité dans mon problème, c'est impeccable je l'ai par héritage.
• Si je n'en ai pas besoin, ben je l'ai aussi.

C'est ce côté "contaminant" (je trouve que ce terme à une connotation beaucoup trop négatif, mais je n'en trouve pas de meilleurs) qui ne m'emballe pas plus que ça. Ceci étant ce n'est pas non plus un problème catastrophique et c'est probablement en grande partie une opinion très subjective.

En effet on peut retrouver ce genre de problématique dans plusieurs bibliothèques notamment dans Java/ Cela s'explique assez facilement par rapport à cette absence en C++.

En effet, d'une part en C++ les pratiques tendent à ce que l'on ne dérive jamais de classes de la bibliothèque standard (qui est surtout la STL) car se serait se tirer une balle gros calibre dans le pied et d'autres part cette bibliothèque est relativement pauvre elle ne couvre pas autant de cas que celle de Java (par exemple les IHM qui est une couche logicielle à part entière ou encore les réseaux) Mais bon je ne suis certainement pas aux goûts du jour de ce qui fait parti du standard et ce qui n'en fait pas parti.

As-tu une documentation à l'instar de la JavaDoc où on peut voir les hiérarchisations des classes standardisées ?

Autrement, je me demande s'il n'existe pas un moyen de faire cacher par l'intellisense (car quand tu dis que tu l'as la méthode Equals je pense que tu parles de cela....) certaines méthodes de classes parentes (pourvu encore que tu utilises un outil avec une intellisense pour le voir )

Préférerais-tu cette forme partielle d'héritage multiple qui ne permet pas le NVI, la validation des contrats, etc. que l'on appelle l'interface ?
Plus sérieusement, en comprenant et respectant le LSP ça ne pose pas tant de soucis que ça et permet de faire des interfaces infiniment plus riches que les interfaces Java.
Autant j'imagine assez bien comment se passer d'héritage multiple dans un langage comme D qui propose des interfaces un peu plus souples/riches que Java, le support de la PpC et autres mixin, autant je n'y arrive pas vraiment en Java.

Ne pas avoir la possibilité de faire de l'héritage multiple ne me pose aucun problème particulier à priori et même en ayant cette possibilité à vrai dire je ne pense pas l'utiliser dans des implémentations. Quand à la validation de contrat j'ai envie de te répondre que tu violes le principe de responsabilité unique voir de forte cohésion en le faisant en utilisant NVI puisque ta classe en plus de sa propre responsabilité va aussi avoir celle de vérifier des contrats. Cela reste assez discutable sur l'aspect conception à mon avis.

Que reproches-tu précisément ?

Son existence, sa complexité et ses risques d'erreurs dans bien des cas mais bon c'est un effet découlant de la conception même du langage. (notamment que tout objet sauf primitif ne soit des références à l'instar de Java)

Quel ordre aurais-tu voulu?

C'est encore plus ou moins lié à la complexité de se retrouver dans l'ordre qui sera réellement exécuté.

Complexité peut-être.
Inutile, non je ne pense pas.

Quant à la "productivité, réactivité et maintenance à moindre coût impossible", vu que j'observe où je travaille et où il y a des projets en C++, en Java et dans d'autres langages, ça ne me semble pas aussi évident que ça (typiquement il y a un projet en Java qui pose de réels problèmes d'évolution et de maintenance, bien plus que les projets en C++ pour une complexité de même ordre de grandeur. Toutefois, je ne pense pas que ça vienne du langage, mais plutôt du framework utilisé et du manque de rigueur d'une partie de l'équipe).

Oui ce n'est pas aussi évident comme réponse mais derrière productivité et maintenance il faut entendre aussi les coûts notamment humains. Est-ce que les équipes Java et C++ dont tu parles sont composées du même nombre de personnes et payées au même prix ?

Certes. Mais le reprocher au langage est assez gonflé. Et l'herbe n'est pas plus verte ailleurs, loin de là.

Pourquoi alors il est à priori (il faudrait trouver des chiffres objectifs effectivement car là c'est péremptoirement gonflé) moins enseigné que le Java ?

Pourtant tout comme Java il existe pleins d'outils et de bibliothèques gratuits ce n'est donc pas une question de coûts. A entendre certains intervenants il y a autant de débouchés en matières d'emploi en C++ que Java. Alors pourquoi ? Et pourquoi les enseignants ont à priori plus de mal à enseigner le C++ que le Java ? Les principes OO restent les mêmes non ?

Peux-tu expliciter ce point ?
En particulier, puis-qu’ici on compare à Java, ce que Java a apporter de plus que C++ dans ce domaine (et on parle bien d'innovation apportée, pas de popularisation de pratiques/concepts existant).

Je pose une question : quelle(s) innovations a apporté ce langage ces 10 dernières années ? (j'ai lu partiellement en grosse mail Luc la dessus, entre autres, et il est vrai que je ne suis plus (et n'est suivi) vraiment boost et Ace...)

Par contre je ne vois pas en quoi, il faut y penser dès le départ ? Ce qu'il faut prévoir dès le départ, c'est la portabilité que l'on souhaite et donc le sous-ensemble utilisable dans ce contexte. Mais c'est vrai dans tout les cas pas uniquement en C++.

Oui et non. Dans un langage compilé comme C++ il faut avoir une portabilité au niveau code alors qu'avec Java le code reste le même et l'effort est déplacé sur l'implémentation d'une nouvelle VM. Nous n'avons donc pas à nous soucier en Java d'organiser du code pour la portabilité. Et par code il faut entendre cela de manière général comme le fait d'acheter ou d'utiliser des composants tiers.

En partie je pense que tu as raison aussi car il est difficile de toute façon de le prévoir complètement dés le départ.

[Luc Hermitte]

1-En effet, d'une part en C++ les pratiques tendent à ce que l'on ne dérive jamais de classes de la bibliothèque standard (qui est surtout la STL) car se serait se tirer une balle gros calibre dans le pied et d'autres part cette bibliothèque est relativement pauvre elle ne couvre pas autant de cas que celle de Java (par exemple les IHM qui est une couche logicielle à part entière ou encore les réseaux) Mais bon je ne suis certainement pas aux goûts du jour de ce qui fait parti du standard et ce qui n'en fait pas parti.

2- As-tu une documentation à l'instar de la JavaDoc où on peut voir les hiérarchisations des classes standardisées ?

3- Ne pas avoir la possibilité de faire de l'héritage multiple ne me pose aucun problème particulier à priori et même en ayant cette possibilité à vrai dire je ne pense pas l'utiliser dans des implémentations. Quand à la validation de contrat j'ai envie de te répondre que tu violes le principe de responsabilité unique voir de forte cohésion en le faisant en utilisant NVI puisque ta classe en plus de sa propre responsabilité va aussi avoir celle de vérifier des contrats. Cela reste assez discutable sur l'aspect conception à mon avis.


4- Oui ce n'est pas aussi évident comme réponse mais derrière productivité et maintenance il faut entendre aussi les coûts notamment humains. Est-ce que les équipes Java et C++ dont tu parles sont composées du même nombre de personnes et payées au même prix ?


5- Alors pourquoi ? Et pourquoi les enseignants ont à priori plus de mal à enseigner le C++ que le Java ? Les principes OO restent les mêmes non ?

1- malgré la présence d'une IHM standard en Java, il y en a pourtant eu d'autres entre eclipse et jambi, je lis qu'il y a eu le message : <<le "standard" (peut-on parler de standard pour le Java ?) n'est pas terrible, voici mieux.>>
En C++ il y a trop d'intérêts commerciaux conflictuels pour imposer une vision unique.

2- La STL n'est pas OO.
Le seul endroit dans la lib standard où il y a de l'héritage, c'est dans les flux. En encore il y aurait des choses à redire.

3- Je suis pourtant sûr que tu fais de l'héritage multiple d'interfaces.
La notion de contrat est au cœur même du LSP. Dire que le LSP est en contraction avec le SRP ... mouais si ça te fais plaisir... :p
Accessoirement, le NVI sépare justement les responsabilités, en plus du contrat :
- il dit à l'utilisateur : "voilà l'interface d'appel que je t'offre"
- et il dit au développeur en charge de la spécialisation : "voilà le seul point de variabilité où tu es autorisé à intervenir".
Dans un mode où tout est virtuel, il faut aller en plus dans la doc pour savoir où sont les vrais points de variabilité.

4- cela me rappelle une discussion avec un collègue : il est plus intéressant (à la mode?) pour une boite d'avoir une horde de pisseurs de code, et quelques pompiers qui viendront éteindre le feu à la fin. En C++, ce modèle coute plus cher/est moins adapté.

5- On rejoint un des premiers points de la présentation de Stepanov : "mais pourquoi est-ce que les profs continuent à enseigner ces hérésies (ce mot est de mon interprétation) algorithmiques que sont le bubble sort ou même le quicksort ?"
La réponse est l'historique : c'est comme ça qu'ils ont appris, c'est comme ça qu'ils enseignent.

[hegros]

2- La STL n'est pas OO.
Le seul endroit dans la lib standard où il y a de l'héritage, c'est dans les flux. En encore il y aurait des choses à redire.

Effectivement cependant cela rejoins l'idée énoncée que plus de problèmes de conceptions objets se posent lorsqu'il y a une bibliothèque objet plus importante et en C++ il n'y en a pas vraiment donc la probabilité d'erreur est quasi-nulle.

3- Je suis pourtant sûr que tu fais de l'héritage multiple d'interfaces.
La notion de contrat est au cœur même du LSP. Dire que le LSP est en contraction avec le SRP ... mouais si ça te fais plaisir... :p
Accessoirement, le NVI sépare justement les responsabilités, en plus du contrat :
- il dit à l'utilisateur : "voilà l'interface d'appel que je t'offre"
- et il dit au développeur en charge de la spécialisation : "voilà le seul point de variabilité où tu es autorisé à intervenir".
Dans un mode où tout est virtuel, il faut aller en plus dans la doc pour savoir où sont les vrais points de variabilité.

Je ne fais pas vraiment plus que cela d'héritage multiple d'interface ni d'héritage de classe de manière générale. Cela ne respecte pas le principe de faible couplage

Pour l'histoire de LSP et SRP je pense avoir mal compris la réponse de gl. Un exemple de validation de contrats vulgarisé et simple à comprendre avec LSP et NVI serait plus parlant. L'exemple dans la Faq n'est pas parlant.

L’ambiguïté sur SRP et la forte cohésion tient du fait que j'imagine une classe x avec ses méthodes fortement cohérentes x' et des méthodes de validation de contrats y qui sortent du domaine de x.

Simplement ce qui me vient à l'esprit, mais cela est réducteur de lsp et nvi, c'est une classe voiture de base avec une méthode freine et une classe dérivée mercedes. Dans voiture.Freine, on vérifierait que les freins sont bien construit avant de freiner ou par virtualisation dans mercedes.Freine :-) J'ai tendance à penser que cette vérification ne devrait se faire ni dans voiture ni dans mercedes.

4- cela me rappelle une discussion avec un collègue : il est plus intéressant (à la mode?) pour une boite d'avoir une horde de pisseurs de code, et quelques pompiers qui viendront éteindre le feu à la fin. En C++, ce modèle coute plus cher/est moins adapté.

Je ne comprends pas ce que tu veux dire. Nous sommes obligés dans le monde du développement logiciel de nous intéresser aux coûts, aux délais et à la qualité et on ne peut avoir le beurre, l'argent du beurre et la crémaillère.

La question que je posais à gl est est-ce que cela coûte le même prix pour un même niveau de qualité d'avoir une équipe en Java ou en C++ pour une même topologie et taille de projet ?

5- On rejoint un des premiers points de la présentation de Stepanov : "mais pourquoi est-ce que les profs continuent à enseigner ces hérésies (ce mot est de mon interprétation) algorithmiques que sont le bubble sort ou même le quicksort ?"
La réponse est l'historique : c'est comme ça qu'ils ont appris, c'est comme ça qu'ils enseignent.

Oui mais ils préfèrent à priori continuer d'enseigner ces hérésies en Java et pas en C++. Donc pour le même résultat il préfère le Java mais pourquoi ?

[koala01]

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

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 )

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 )

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

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

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!

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à

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à

-les constructeurs par recopie

Je te signale, en passant, que les constructeurs par recopie font simplement partie de la forme canonique de Coplien

-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

-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

Le jour où il n'y aura plus de variables globales en C, elles disparaitront de facto en C++

-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

-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

-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 )

-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

-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

-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

-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

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

[hegros]

Tu te focalise sur la fonction Equals

Parce que c'est l'exemple type du mauvais exemple et que les échanges ont tourné autour de cela, tout simplement. On peut passer à un autre sujet maintenant puisque le tour a été fait autour de Object.Equals.

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.

Beh si j'ai bien compris, d'autant plus que la responsabilité est de 50/50 soit une part de celui qui écrit et une part de celui qui lit

Combien de fois utilises tu le mot clé implements dans un projet java

Je ne programme pas en Java mais en C# Mais Object est aussi présent Sinon oui j'utilise plus souvent une implémentation d'interface que l'héritage.

Mais, si tu as décidé de croire que je n'en ai qu'à la fonction Equals, la discussion ne mènera nulle part

Non je ne crois rien à cela, tes arguments sont en parties justifiés (quand j'arrive à les comprendre ) mais permet moi quand même de tenir en partie le rôle de contradicteur afin de faire ressortir la moelle de ces arguments et de mettre en suspens ce qui est ambigu et non fondé à mon sens. A moins que tu préfères que les intervenants jouent le rôle du béni oui oui

[gl]

As-tu une documentation à l'instar de la JavaDoc où on peut voir les hiérarchisations des classes standardisées ?

Si tu parles d'un graphe de hiérarchie des classes standard, non je n'en ai pas (n'en ayant jamais eu besoin je n'ai jamais cherché).
Une bonne doc sur le standard, oui. Par exemple chez Dinkumware.

Autrement, je me demande s'il n'existe pas un moyen de faire cacher par l'intellisense (car quand tu dis que tu l'as la méthode Equals je pense que tu parles de cela....) certaines méthodes de classes parentes (pourvu encore que tu utilises un outil avec une intellisense pour le voir )

Non mon problème n'est pas la vision mais la disponibilité de la fonctionnalité. Je ne peux pas, à ma connaissance, écrire une classe ne possédant pas de equals, tout ou plus dire comment faire le test. Après je conçois très bien qu'il y ait des raisons techniques et/ou philosophiques derrière ce choix, mais ce n'est pas seulement que j'attends.

Ne pas avoir la possibilité de faire de l'héritage multiple ne me pose aucun problème particulier à priori et même en ayant cette possibilité à vrai dire je ne pense pas l'utiliser dans des implémentations. Quand à la validation de contrat j'ai envie de te répondre que tu violes le principe de responsabilité unique voir de forte cohésion en le faisant en utilisant NVI puisque ta classe en plus de sa propre responsabilité va aussi avoir celle de vérifier des contrats. Cela reste assez discutable sur l'aspect conception à mon avis.

Ce n'est pas la classe qui à la responsabilité du contrat mais l'interface (dont c'est justement le rôle puisque c'est elle qui "publie" les méthodes disponibles, le type des paramètres, etc.).

Son existence, sa complexité et ses risques d'erreurs dans bien des cas mais bon c'est un effet découlant de la conception même du langage. (notamment que tout objet sauf primitif ne soit des références à l'instar de Java)

Je veux bien admettre ton argument si tu m'explique comment je peux moi définir, en Java ou dans un autre langage ou tout les objets sauf primitif ne sont que des références, une type à sémantique de valeur.

Au passage, en première approche, je trouve l'approche de D [1] de ce problème intéressante.

C'est encore plus ou moins lié à la complexité de se retrouver dans l'ordre qui sera réellement exécuté.

Ce n'était pas une question piège de ma part, mais une vrai interrogation. Et ta réponse ne m'aide pas vraiment à comprendre ton point. Peux-tu préciser.

Oui ce n'est pas aussi évident comme réponse mais derrière productivité et maintenance il faut entendre aussi les coûts notamment humains. Est-ce que les équipes Java et C++ dont tu parles sont composées du même nombre de personnes et payées au même prix ?

Non, sur le projet Java qui pose de souci, il y a plus de monde (et je soupçonne que ça contribue au problème). Sur les autres, le nombre de personne est sensiblement équivalent. Pour les salaires je n'ai pas la grille complète, mais pour ce que je connais oui c'est assez proche.

Maintenant, encore une fois je pense que notre souci est organisationnel et pas du tout lié au langage. Mon point est juste que je réfute l'argument : "fais un projet en Java il sera plus rapide à développer, à maintenir, etc." c'est malheureusement loin d'être aussi simple et d'autres critères interviennent.

Tout comme je réfute, pour les mêmes raisons, l'argument : "fais ton projet dans la langage X plutôt que dans le langage Y, ça sera beaucoup plus rapide".

Pourquoi alors il est à priori (il faudrait trouver des chiffres objectifs effectivement car là c'est péremptoirement gonflé) moins enseigné que le Java ?

Déjà je n'ai pas connaissance de chiffres fiables à ce sujet (non, que je prétende que l'hypothèse est fausse, seulement que je n'en sais rien). Mais je vois plusieurs raisons possibles :

• Un phénomène de mode.
• Un cercle : on forme des gens au Java ==> on commence à utiliser Java professionnellement ==> il y a une demande de développeur Java ==> on forme plus de gens à Java, etc.
• L'aspect multi-paradigme du C++.
• Une courbe d'apprentissage différente.

Même si Accelerated C++ et le dernier Stroustrup montre le contraire, je ne suis pas forcément fan du C++ pour apprendre la programmation (mais je ne pense pas que Java soit beaucoup mieux).

Je pose une question : quelle(s) innovations a apporté ce langage ces 10 dernières années ? (j'ai lu partiellement en grosse mail Luc la dessus, entre autres, et il est vrai que je ne suis plus (et n'est suivi) vraiment boost et Ace...)

Effectivement boost, Ace. J'aurais bien parlé aussi de Modern C++ design et Loki mais c'est un poil plus vieux que 10 ans.
D'une manière générale la metaprog.

Mais effectivement, ce n'est pas forcément de C++ que les plus grosses innovations viennent.
Mais ça reste vrai des langages mainstream globalement, ils innovent peu et reprennent des choses existant par ailleurs (et parfois les popularisent).
De mon point de vue c'est plutôt une bonne chose (ce n'est pas ce que j'attends de ces langages).

Simplement ce qui me vient à l'esprit, mais cela est réducteur de lsp et nvi, c'est une classe voiture de base avec une méthode freine et une classe dérivée mercedes. Dans voiture.Freine, on vérifierait que les freins sont bien construit avant de freiner ou par virtualisation dans mercedes.Freine :-) J'ai tendance à penser que cette vérification ne devrait se faire ni dans voiture ni dans mercedes.

Je préférerais un support natif des contrats dans le langage mais en l'absence de ce support, je trouve la solution NVI préférable à l'utilisation d'un préprocesseur ou d'une métalangage.

Je ne comprends pas ce que tu veux dire. Nous sommes obligés dans le monde du développement logiciel de nous intéresser aux coûts, aux délais et à la qualité et on ne peut avoir le beurre, l'argent du beurre et la crémaillère.

La question que je posais à gl est est-ce que cela coûte le même prix pour un même niveau de qualité d'avoir une équipe en Java ou en C++ pour une même topologie et taille de projet ?

Ce dont Luc parle ici est d'une "méthode" de gestion de projet en Java qui consiste à embaucher plein de développeur à faible coup pour avoir rapidement un truc qui marchotte à peu prés puis deux-trois experts pour rendre le tout pas trop pourri à défaut d'être bon. Méthode qui aurait un coût beaucoup plus élevé en C++.
Comme tu le dis fait remarquer, le but est ici est de réduire fortement les coûts et délai, même si la qualité en pâtit fortement (développement low-cost ?). Je ne sais pas si cette méthode est très répandue ou non, mais ce n'est pas la première que j'en entends parler.




[1] Ce n'est pas la première fois que je cite D dans cette discussion tout simplement car je suis en train de lire le livre d'Alexandrescu et, même si je ne pratique pas ce langage et que je ne suis pas du tout certain qu'il perce, j'y trouve de nombreux choix de design intéressant.

[hegros]

Si tu parles d'un graphe de hiérarchie des classes standard, non je n'en ai pas (n'en ayant jamais eu besoin je n'ai jamais cherché).
Une bonne doc sur le standard, oui. Par exemple chez Dinkumware.

Oui un graphe car Dinkumware je connaissais déjà. Cependant vu que 90% du standard c'est la STL il y a probablement peu d’intérêt en plus du fait que la STL c'est plus des définitions d'opérateurs que des méthodes et que ce n'est pas OO (dixit Luc)

D'un point de vue conception je me demande si c'est vraiment comparable avec Java pour le coup. Comparer une conception OO avec une conception qui ne l'est est quelque peu dérangeant...

Non mon problème n'est pas la vision mais la disponibilité de la fonctionnalité. Je ne peux pas, à ma connaissance, écrire une classe ne possédant pas de equals, tout ou plus dire comment faire le test. Après je conçois très bien qu'il y ait des raisons techniques et/ou philosophiques derrière ce choix, mais ce n'est pas seulement que j'attends.

Qu'est-ce qui te gêne dans la disponibilité de la fonctionnalité ? Que tu puisses mal l'utiliser malgré la littérature qui existe dessus pour expliquer sa présence ? L'aspect runtime qui charge du byte code non utilisé ?

Je ne comprends pas ta remarque sur le test, est-ce que tu peux détailler un peu plus cet aspect ?

Je veux bien admettre ton argument si tu m'explique comment je peux moi définir, en Java ou dans un autre langage ou tout les objets sauf primitif ne sont que des références, une type à sémantique de valeur.

En utilisant typedef.

Ce n'était pas une question piège de ma part, mais une vrai interrogation. Et ta réponse ne m'aide pas vraiment à comprendre ton point. Peux-tu préciser.

C'est le fait qu'il n'y a rien de naturel dans l'ordre des appels et que cela peut vite se compliquer avec des hiérarchies de classes importantes.

Dans le cas de l'héritage multiple avec du virtuel il me semble que c'est encore plus ambigu et problématique car si plusieurs classes mères possèdent un même attribut alors il n'y a qu'un seul attribut d'une des classes mères qui est utilisable par une classe qui hérite de toutes ces classes mères.

Du coup, les attributs des autres classes mères ne servent à rien dans cette classe dérivée et ne sont plus utilisables ce qui entraîne fatalement de la duplication inutile d'attribut (après pour ce qui est monté en mémoire je me demande si c'est aussi dupliqué, inutilisable et donc gaspilleurs de ressources)

D'une manière générale la metaprog.

Effectivement de ce point de vue là je suis d'accord.

Ce dont Luc parle ici est d'une "méthode" de gestion de projet en Java qui consiste à embaucher plein de développeur à faible coup pour avoir rapidement un truc qui marchotte à peu prés puis deux-trois experts pour rendre le tout pas trop pourri à défaut d'être bon. Méthode qui aurait un coût beaucoup plus élevé en C++.

Comme tu le dis fait remarquer, le but est ici est de réduire fortement les coûts et délai, même si la qualité en pâtit fortement (développement low-cost ?). Je ne sais pas si cette méthode est très répandue ou non, mais ce n'est pas la première que j'en entends parler.

Merci pour l'éclaircissement je comprends mieux et cela se recoupe bien avec ce que tu exposais comme problème organisationnel plus que de langage ou de bibliothèques. Ce n'est effectivement pas si simple de démontrer une meilleure productivité et diminution de la maintenance en ne prenant que l'aspect langage/bibliothèque car il y a plusieurs variables explicatives à prendre en compte notamment l'aspect qualité (qui reste subjective à moins de se référer à l'iso) et l'aspect organisationnel.(qui reste subjective à moins de se référer à l'iso ;p )

Quoi il n'y a pas eu de projet concours lancé sur developpez.com pour réaliser un même projet avec 2 technos et équipes différentes qui soient comparables ? Et évaluez le résultat qualitativement via l'iso

[gl]

Cependant vu que 90% du standard c'est la STL il y a probablement peu d’intérêt en plus du fait que la STL c'est plus des définitions d'opérateurs que des méthodes et que ce n'est pas OO (dixit Luc)

Tout à fait.

D'un point de vue conception je me demande si c'est vraiment comparable avec Java pour le coup. Comparer une conception OO avec une conception qui ne l'est est quelque peu dérangeant...

Oui et non. Chacun permettant des choses que l'autre ne permet on ne va effectivement pas concevoir le programme de la même façon en Java qu'en C++.

Qu'est-ce qui te gêne dans la disponibilité de la fonctionnalité ? Que tu puisses mal l'utiliser malgré la littérature qui existe dessus pour expliquer sa présence ? L'aspect runtime qui charge du byte code non utilisé ?

Parfois je n'ai pas besoin ou ne souhaite pas que ma classe soit comparable. Là je n'ai pas le choix.

Je ne comprends pas ta remarque sur le test, est-ce que tu peux détailler un peu plus cet aspect ?

Je parlais du test d'égalité. Je me récupère forcément equals mais je peux tout de même définir de quelle façon est réalisée la comparaison.

En utilisant typedef.

A moins d'être passé à côté de quelque-chose, les fonctionnalités du style de typedef permettent de définir des alias sur des types (et donc effectivement appliqué à un type primitif de créer des alias sur des types ayant une sémantique de valeur), pas de définir mes propres classes avec une sémantique de valeur.
Du coup on se retrouve plutôt avec du clonage explicite, parfois sur des classes immutables, etc. Ce qui parfois correspond vraiment à ce que l'on souhaite faire (et je peux le faire en C++) mais pas toujours et là ça coince.

C'est d'ailleurs mon plus gros problème avec Java (mais pas uniquement) : il m'impose une façon de voir les choses qui n'est pas forcément la plus adaptée à mon problème courant. Ça a aussi des avantages, le code est généralement plus homogène, les développeurs sont plus facilement remplaçables, etc. mais ce n'est pas ce que moi je recherche.

C'est le fait qu'il n'y a rien de naturel dans l'ordre des appels et que cela peut vite se compliquer avec des hiérarchies de classes importantes.

On construit de la base vers la fille et on détruit dans le sens contraire. C'est assez simple et logique.

Dans le cas de l'héritage multiple avec du virtuel il me semble que c'est encore plus ambigu et problématique car si plusieurs classes mères possèdent un même attribut alors il n'y a qu'un seul attribut d'une des classes mères qui est utilisable par une classe qui hérite de toutes ces classes mères.

Oui dans ce cas là, c'est effectivement un peu plus compliqué.

Du coup, les attributs des autres classes mères ne servent à rien dans cette classe dérivée et ne sont plus utilisables ce qui entraîne fatalement de la duplication inutile d'attribut

Ce n'est pas aussi simple. Comme déjà signalé à plusieurs reprises par Luc (dans ce fil et dans d'autres), une bonne partie des problèmes rencontrés dans ce cas proviennent de hiérarchie de classe boiteuse faite par des personnes ne comprenant pas vraiement LSP. Ne pas avoir d'héritage multiple masque partiellement les effets du problème mais ne le résolve pas.

Il y a d'autre cas qui peuvent poser problème, mais c'est beaucoup plus marginale et ça se règle au cas par cas.

Quoi il n'y a pas eu de projet concours lancé sur developpez.com pour réaliser un même projet avec 2 technos et équipes différentes qui soient comparables ? Et évaluez le résultat qualitativement via l'iso

En pratique ça me semble difficilement faisable!

[davcha]

Juste une question concernant equals de java. Notez que je ne connais pas la réponse.

equals est commutatif ? Comment cela se passe-t-il avec un equals "overridé" ?

Typiquement ce cas là :

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
class A{
  public boolean equals(Object obj){
    //affiche "toto"
    return obj == this;
  }
}
class B{
  public boolean equals(Object obj){
    //affiche "tati"
    return obj == this;
  }
}
A a;
B b;
a.equals(b);
b.equals(a);

Qu'est-ce qui est affiché ?

Cet argument là me parait meilleur que les délires à base de comparaison de voiture et chou fleur. J'entends par là qu'il est toujours intéressant de pouvoir comparer l'identité de deux objets par leur adresses respectives, quelque soit le type de l'objet. C'est un mécanisme qui se retrouve en C++, d'ailleurs. Par contre, modifier le comportement de ce mécanisme me semble très hasardeux.

[hegros]

Parfois je n'ai pas besoin ou ne souhaite pas que ma classe soit comparable. Là je n'ai pas le choix.

En déclarant ta classe private elle ne serait comparable que par les autres objets appartenant à son package ce qui restreint d'autant plus les possibilités que ta classe soit comparable par n'importe qui de l'extérieur. Alors biensûr cela force des designs particuliers donc à moins d'avoir une bonne raison que tu ne souhaites pas que ta classe soit comparable..

[gl]

En déclarant ta classe private elle ne serait comparable que par les autres objets appartenant à son package ce qui restreint d'autant plus les possibilités que ta classe soit comparable par n'importe qui de l'extérieur.

Mais dans ce cas, elle n'a pas du tout utilisable en dehors du package, n'est-ce pas ?

[zaventem]

Pour ma part, Equals me pose un problème beaucoup plus fondamental (même si je vis très bien avec et que cela ne perturbe pas mes nuits ) : à de rares exceptions près (mais c'est alors un choix sensé être réfléchi), ce n'est pas de la responsabilité d'un objet de se comparer à un autre.

Pour reprendre l'exemple des véhicule, une voiture ne se compare pas à une moto mais c'est bien moi qui le fait, selon mes critères qui seront différents de ceux du garagiste qui seront eux-mêmes différents de ceux de ma petite nièce.

[hegros]

Mais dans ce cas, elle n'a pas du tout utilisable en dehors du package, n'est-ce pas ?

oui

[kisitomomotene]

Pour ma part, Equals me pose un problème beaucoup plus fondamental (même si je vis très bien avec et que cela ne perturbe pas mes nuits ) : à de rares exceptions près (mais c'est alors un choix sensé être réfléchi), ce n'est pas de la responsabilité d'un objet de se comparer à un autre.

Pour reprendre l'exemple des véhicule, une voiture ne se compare pas à une moto mais c'est bien moi qui le fait, selon mes critères qui seront différents de ceux du garagiste qui seront eux-mêmes différents de ceux de ma petite nièce.

Et qu'est ce que une voiture fait d'elle même? ce n'est pas une voiture qui se démarre elle même, ce n'est pas une voiture qui se clignote d'elle même. Donc la classe voiture devrait seulement avoir des propriétés mais pas de méthodes? je pense qu'on donne à une classe la responsabilité d’exécuter une méthode, lorsque cette classe à toutes les informations en interne pour accomplir la tâche demandée.
Ainsi si on veut mettre la méthode Equal en dehors de la classe voiture, on peut se retrouver obligé d'exposer en externe certaines propriétés privées de voitures, brisant ainsi le principe d'encapsulation!

[Luc Hermitte]

Je ne fais pas vraiment plus que cela d'héritage multiple d'interface ni d'héritage de classe de manière générale. Cela ne respecte pas le principe de faible couplage

Pour l'histoire de LSP et SRP je pense avoir mal compris la réponse de gl. Un exemple de validation de contrats vulgarisé et simple à comprendre avec LSP et NVI serait plus parlant. L'exemple dans la Faq n'est pas parlant.

L’ambiguïté sur SRP et la forte cohésion tient du fait que j'imagine une classe x avec ses méthodes fortement cohérentes x' et des méthodes de validation de contrats y qui sortent du domaine de x.

Simplement ce qui me vient à l'esprit, mais cela est réducteur de lsp et nvi, c'est une classe voiture de base avec une méthode freine et une classe dérivée mercedes. Dans voiture.Freine, on vérifierait que les freins sont bien construit avant de freiner ou par virtualisation dans mercedes.Freine :-) J'ai tendance à penser que cette vérification ne devrait se faire ni dans voiture ni dans mercedes.

La programmation par contrat.
Toute la question est de savoir si on se contente de vérifier les conditions nécessaires induites par le contexte (genre on ne permet pas de rouler à plus de 20km/h avec la porte ouverte), ou de vérifier des erreurs de programmation.
Initialement, j'ai l'impression que le texte de Bertrand Meyer était plus dans le premier cadre.
Aujourd'hui je ne fais que la PpC pratiquement uniquement dans le second cadre.
Donc, en C++, j'enforce le LSP de mes classes via la pattern NVI (parmi d'autres outils). Vérification d'erreurs -> assertions. Et l'endroit le plus simple pour faire la vérification, c'est en entrée de la fonction appelée (dans le cadre des préconditions). Pourquoi en entrée alors que c'est à l'appelant de vérifier que les préconditions sont bien respectées ? Justement pour un principe de DRY et de responsabilités : c'est l'appelé qui est le mieux à même de réaliser la vérification, car il se souviendra toujours de ce qu'il attend.

D'ailleurs, en Eiffel, la spécification du contrat est bien au niveau de l'appelé.

Au final, un exemple abstrait ressemble à ça : http://www.developpez.net/forums/d11...e/#post6304603
Voir aussi: http://www.developpez.net/forums/d85...plication-cpp/

Oui un graphe car Dinkumware je connaissais déjà. Cependant vu que 90% du standard c'est la STL il y a probablement peu d’intérêt en plus du fait que la STL c'est plus des définitions d'opérateurs que des méthodes et que ce n'est pas OO (dixit Luc)

C'est Stepanov qui est connu pour cela.

D'un point de vue conception je me demande si c'est vraiment comparable avec Java pour le coup. Comparer une conception OO avec une conception qui ne l'est est quelque peu dérangeant...

Stepanov est connu pour critiquer la POO, http://www.artima.com/cppsource/type_erasure.html
Une fois de plus, regarde la video que j'ai postée. Tu en apprendra bien plus en une heure sur le design d'une lib de base qu'en une semaine à pinailler avec nous ici :p. Ou du moins de nouvelle questions germeront et elles devraient te mettre sur la piste de pourquoi les choix faits sont si différents.

[Luc Hermitte]

Ainsi si on veut mettre la méthode Equal en dehors de la classe voiture, on peut se retrouver obligé d'exposer en externe certaines propriétés privées de voitures, brisant ainsi le principe d'encapsulation!

Le problème fondamental, c'est que comparer selon l'égalité deux voitures (entités) n'a strictement aucune sens!
Après interne ou externe, il n'y a aucun différence.
Si on sait qu'il y a une fonction qui doit être libre, et qu'elle doit accéder aux détails d'implémentation d'une classe, il suffit de comprendre qu'elle fait partie de l'interface étendue de la classe et de valider son autorisation à voir les détails en la rendant amie, elle et nulle autre fonction (exactement comme pour les fonctions membres). L'encapsulation n'est pas rompue, bien au contraire vu qu'aucune propriété inutile n'est alors exposée.

[kisitomomotene]

Le problème fondamental, c'est que comparer selon l'égalité deux voitures (entités) n'a strictement aucune sens!
Après interne ou externe, il n'y a aucun différence.
Si on sait qu'il y a une fonction qui doit être libre, et qu'elle doit accéder aux détails d'implémentation d'une classe, il suffit de comprendre qu'elle fait partie de l'interface étendue de la classe et de valider son autorisation à voir les détails en la rendant amie, elle et nulle autre fonction (exactement comme pour les fonctions membres). L'encapsulation n'est pas rompue, bien au contraire vu qu'aucune propriété inutile n'est alors exposée.

Les classes/fonctions amies n'existent pas en Java!