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

[wafiwafi]

Merci à tous pour vos pertinentes réponses.

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

Y a -t- il un lien à me fournir; ça serait pas mal.

[bruno_pages]

IL y en a un dans la réponse de Goten : héritage virtual

[wafiwafi]

Ah, ok! Je l'avais déjà consulté et bien suivi.
Merci à toi

[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é.
...

[bruno_pages]

bacelar, cela est trop artificiel et surtout trop ad hoc pour dire qu'il y à quelque chose d'intéressant de commun. Si on veut absolument que deux classes aient quelque chose en commun alors on trouvera toujours, mais cela ne veut pas dire que cela à un vrai sens.

personnellement cela fait pas mal d'années que je programme et ne me souviens pas avoir eu à subir un losange de la mort / héritage virtuel

[koala01]

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

Mhhhh... Oui, mais non...

Demande toi surtout s'il te semble cohérent de permettre de faire cohabiter des objets de ces différents types dans une collection "unique" et l'usage que tu pourrais en faire...

Les services que tu présentes ici sont beaucoup trop... génériques pour que cela puisse avoir le moindre intérêt, parce que, si tu décide de permettre de les cloner, par exemple, ce sera pour mettre un patron "fabrique" en place.

Or, il ne me semble pas cohérent de demander à la même fabrique de nous renvoyer une fois un chien, une fois une voiture et une fois une petite cuiller

Tu pourrais, effectivement, envisager de créer une interface "IClonable" qui serait commune à tous ces types, mais cette interface ne devrait pas mettre en relation deux hiérarchies qui n'ont strictement rien à voir entre elles (la hiérarchie "animal" et la hiérarchie "véhicule").

Or, justement, la programmation générique, permet d'éviter de relier ces deux hiérarchies de classe:

Dans un code proche de

Code :

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
17
18
19
template <class T>
class IClonable
{
    public :
        T * clone() const{return new T(*this);}
        /*...*/
    private:
        T();
        T(T const &);
};
class Animal : public IClonable<Animal>
{
    /*...*/
};
class Vehicule : public IClonable<Vehicule>
{
    /*...*/
};
/* suivent des types dérivant de Animal et / ou de Vehicule */

ne reliera absolument pas les deux hiérarchies

En outre, même si (je déconseillerai toujours de le faire ) on venait à utiliser une class IClonable "classique" (non template), il y a peu de chances que tu finisse un jour par vouloir faire hériter un objet de Animal et de Vehicule (ou d'un des types dérivés): le char à boeufs, c'est un véhicule, mais le "à" indique bel et bien que les boeufs interviennent dans une aggrégation / composition et non dans un héritage

[koala01]

bacelar, cela est trop artificiel et surtout trop ad hoc pour dire qu'il y à quelque chose d'intéressant de commun. Si on veut absolument que deux classes aient quelque chose en commun alors on trouvera toujours, mais cela ne veut pas dire que cela à un vrai sens.

personnellement cela fait pas mal d'années que je programme et ne me souviens pas avoir eu à subir un losange de la mort / héritage virtuel

Je suis tout à fait d'accord avec toi...

Bien souvent, le losange de la mort survient parce que l'on a pris, à la base, des décisions inadaptées et, d'une certaine manière, totalement contraires au LSP

[bacelar]

Les services que tu présentes ici sont beaucoup trop... génériques pour que cela puisse avoir le moindre intérêt

C'est là tout l'intérêt, vu qu'ils s'appliquent à tous les objets.
Avoir une collection d'objet permet, par exemple l'implémentation d'un garbage collector, etc...

[koala01]

C'est là tout l'intérêt, vu qu'ils s'appliquent à tous les objets.
Avoir une collection d'objet permet, par exemple l'implémentation d'un garbage collector, etc...

Hou la la... Tu semble avoir raté le débat sur l'utilité d'un garbage collector en C++... ou être beaucoup trop imprégné de la mentalité java (cette dernière remarque ne doit être prise que pour ce qu'elle est: une boutade dite sans la moindre trace péjorative, hein ).

En gros, on pourrait dire qu'il n'y a strictement aucun intérêt à envisager un garbage collector en C++ grâce à la flopée des pointeurs intelligents dont on dispose, soit au travers de la STL, soit grâce à boost

[bacelar]

Cela ne règle pas les problèmes de localité, compactage mémoire, optimisation de parcours d'arborescence, adaptabilité transparente aux limitations de la plateforme pour des algorithmes de systèmes particulaires par exemple ...

Ne jamais se privé d'un outil simplement parce que l’on ne sait pas s'en servir.
Savoir sans servie, c'est aussi savoir quand il n'est pas utile.

[koala01]

Cela ne règle pas les problèmes de localité, compactage mémoire, optimisation de parcours d'arborescence, adaptabilité transparente aux limitations de la plateforme pour des algorithmes de systèmes particulaires par exemple ...

Si ce n'est que tous ces problèmes trouvent une solution élégante en C++ qui ne nécessite aucunement le recours à un garbage collector

Ne jamais se privé d'un outil simplement parce que l’on ne sait pas s'en servir.
Savoir sans servie, c'est aussi savoir quand il n'est pas utile.

Le fait est, qu'en l'occurrence, un garbage collector n'est... absolument pas utile en C++...

Surtout au vu de la nouvelle norme