Discussion :

[wafiwafi]

Bonjour,
Pour les habitués de programmation en C++, voila une affirmation pour laquelle j'aimerais avoir vos critiques:

On sait que l'héritage multiple est autorisé en C++. Il y a donc un risque important de "losange de la mort".
Voila mon affirmation :
Il est conseillé aux programmeur de faire appel aux classes abstraites sans implémentation (classes virtuelles purs) en cas d'héritage multiple en C++. Les priver des champs (sauf pour les constantes) permet de minimiser davantage les risques de conflit.

C'est l'équivalent d'interface en JAVA.

[Goten]

Et c'est pour ça qu'on a créer l'héritage virtuel ...

[wafiwafi]

J'en conclus que ma citation est correct?
Merci

[Goten]

J'ai jamais dis ça. J'ai dis que le langage nous fourni un moyen de répondre à la problématique que tu poses (héritage en losange) par le biais de l'héritage virtuel.

[Luc Hermitte]

Commençons par comprendre le LSP, et l'héritage multiple passera mieux...

De plus, Les classes abstraites pures ne sont pas toujours la panacée, cf le pattern NVI et son application directe à la programmation par contrat.

PS: "classe virtuelle" n'existe pas. Une classe de base peut être virtuelle relativement à un héritage. Une classe peut ne disposer que de fonction membre virtuelles pures (et c'est autre chose).

[wafiwafi]

Merci pour ces réponses.
Visiblement le C++ ne s'est pas contenté d'un équivalent d' utilisation d'interface de JAVA pour résoudre le problème du losange. Je vais me pencher dans l'application de l'héritage virtuel et surtout comment il est bâti.
En tout cas merci de m'avoir remis au bon chemin.

[Goten]

et surtout comment il est bâti.

Hu? C'est un détail d'implémentation du langage ça ...

ah voilà je le trouvais plus, y'a un item dans la faq :
http://cpp.developpez.com/faq/cpp/?p...RITAGE_virtuel

[bruno_pages]

C++ ne s'est pas contenté d'un équivalent d' utilisation d'interface de JAVA.

non, heureusement !

oh, il y a de beaux diagrammes UML dans la FAQ

[koala01]

Salut,

Peut être serait il bon d'insister une fois de plus sur ce qu'a mis luc en avant, à savoir

Commençons par comprendre le LSP, et l'héritage multiple passera mieux...
<snip>

L'un des grands reproches que l'on puisse faire à java (par exemple), c'est de considérer que tout hérite implicitement d'un "super objet".

Quand on y regarde de plus près, le super objet (ou similaire) est le principal problème qui risque de provoquer le fameux losange de la mort et représente quelque part une très grosse infraction à LSP (Liskov Substitution Principle).

En effet, LSP met en évidence l'importance qu'il y a à assurer la substituabilité d'un objet du type de base avec un objet du type dérivé lors de l'héritage: Lorsque tu envisage l'héritage public, tu dois pouvoir faire cohabiter n'importe quel objet dont le type se trouve dans la hiérarchie de classes que tu crée, y compris, les types qui dérivent des types qui dérivent (et ainsi de suite) de ton type de base.

Lorsque tu décide de te baser sur un super objet, ou, du moins, sur un type de base trop générique, tu en arrive, selon Liskov, à admettre de faire cohabiter des voitures, des clients et des chiens (ou des poux) dans une seule et même collection d'objets.

Or, il semble évident qu'il te sera impossible de trouve le moindre service commun qui soit rendu par ces différents types .

A l'inverse, si tu n'envisage effectivement l'héritage public que pour les types pour lesquels la substituabilité est établie (un turbo compresseur héritant d'une turbine et d'un compresseur, ces deux derniers n'ayant aucun héritage commun, parce que ne rendant aucun service similaire ), le risque de te retrouver face à un losange de la mort s'amenuise énormément

De plus, C++ fournit un autre paradigme des plus intéressants, qui te permet de contourner les risques résiduels: le paradigme générique.

L'idée est simple, mais, pour la développer, je vais schématiser (au moins sommairement) les trois paradigmes en présence:

Le premier paradigme qui a été mis en oeuvre (par C, par exemple) était le paradigme procédural: on s'inquiète, en priorité, au données que l'on doit traiter.

Avec la complexification des applications, un deuxième paradigme a été envisagé: le paradigme Orienté Objet.

On ne s'intéresse plus aux données en tant que telles, mais bien au services que l'on attend d'elles (en plus d'assurer la substituabilité, s'il échoit).

Le paradigme générique, enfin, s'intéresse moins au service que l'on attend des données à gérer qu'à... la manière dont les données sont gérées.

On remarque en effet que la manière dont une liste d'objet sera gérée sera identique que nous gérions une liste de petites cuillers, une liste de personnes, une liste de voitures, ou la liste des animaux d'un zoo.

En C++, le paradigme générique est mis en oeuvre grâce aux classes et aux fonction template.

Et, chose assez sympa, si on a une classe template MaClass, les spécialisations MaClass<int> et MaClass<UnTypeQuelconque> représentent, de fait, deux types tout à fait distincts, et permettent donc, lorsqu'elles interviennent dans un héritage, d'avoir une interface strictement identique mais... d'éviter le losange de la mort.

Au final, j'aurais presque tendance à dire que la crainte du losange de la mort, pour compréhensible qu'elle soit, est beaucoup plus induite par la méconnaissance (pour ne pas dire de l'ignorance délibérée) d'un principe de base que d'un problème réellement inévitable.

Alors, bien sur, il restera toujours, tout en utilisant l'ensemble des possibilités offertes (respect stricte de LSP et programmation générique) quelques exceptions qui feront que l'on peut malgré tout y être confronté un jour ou l'autre, et qui justifient, à elles seules, d'attirer l'attention sur le risque potentiel qu'il représente...

Pour ces exceptions, la réponse est simple: quand on est confronté, malgré tout le soin que l'on peut apporter à la situation, à la création d'un losange de la mort, il faut envisager... l'héritage virtuel

[bacelar]

Or, il semble évident qu'il te sera impossible de trouve le moindre service commun qui soit rendu par ces différents types .

Et bien moi, si.
Le fait qu'un objet est égale à un autre, sémantique variable en fonction du type d'objet.
Le type de l'objet pour utilisation de la réflexion.
Le fait de pouvoir le cloner, sémantique variable en fonction du type d'objet.
Le délesté de la mémoire s'il n'est plus utilisé.
...