Le concept des interfaces existaient avant Java... C'est très utilisé en SystemC par exemple.
Je n'ai pas dit le contraire.
C'est la seul utilisation "propre" que j'ai vu de l'héritage multiple. Le problème des diamants devient énorme
Là, je ne suis pas d'accord. Personne n'oblige un programmeur C++ à coder en diamant et réciproquement, personne ne devrait en être empeché. Ce n'est pas parce que c'est difficile que ce n'est pas propre. Ce qui l'est, c'est la manière de contourner le problème sans le résoudre.
La seule raison, à mon avis, pour laquelle Java ne propose pas l'héritage multiple à ses programmeurs est l'obligation de dériver de Object, parce que là, on aurait systématiquement un diamant à la moindre classe dérivée multiple.
Il n'empêche qu'il y a réellement des classes qui dérivent de plusieurs objets de même importance (genre : Camion-Benne = Camion + Benne + dispositif d'arrimage prope) et que c'est très chiant de devoir faire le choix d'une classe "majeure" dont héritera l'objet quand les autres ne seront que réimplémentés. Et trancher en faveur du tout-interface (autrement dit, renoncer à l'héritage) ne m'amuse pas plus.
Si les ambigüités du diamant posent problème, alors il suffit de toutes les redéfinir dans la classe héritante en une seule fois, ce qui est en substance ce qu'une interface oblige à faire. Mais se repalucher le même code 15 fois de suite, ça va bien cinq minutes ...
[^] # Re: héritage multiple en diamant
Posté par Obsidian . En réponse au message Autour de l'héritage multiple et des méthodes virtuelles.. Évalué à 4.
Je n'ai pas dit le contraire.
Là, je ne suis pas d'accord. Personne n'oblige un programmeur C++ à coder en diamant et réciproquement, personne ne devrait en être empeché. Ce n'est pas parce que c'est difficile que ce n'est pas propre. Ce qui l'est, c'est la manière de contourner le problème sans le résoudre.
La seule raison, à mon avis, pour laquelle Java ne propose pas l'héritage multiple à ses programmeurs est l'obligation de dériver de Object, parce que là, on aurait systématiquement un diamant à la moindre classe dérivée multiple.
Il n'empêche qu'il y a réellement des classes qui dérivent de plusieurs objets de même importance (genre : Camion-Benne = Camion + Benne + dispositif d'arrimage prope) et que c'est très chiant de devoir faire le choix d'une classe "majeure" dont héritera l'objet quand les autres ne seront que réimplémentés. Et trancher en faveur du tout-interface (autrement dit, renoncer à l'héritage) ne m'amuse pas plus.
Si les ambigüités du diamant posent problème, alors il suffit de toutes les redéfinir dans la classe héritante en une seule fois, ce qui est en substance ce qu'une interface oblige à faire. Mais se repalucher le même code 15 fois de suite, ça va bien cinq minutes ...