Discussion :

[Alp]

Pour ma part, c'est pour l'héritage multiple, cf les posts de Loïc, Luc et r0d pour les raisons.
Pour le surcoût, disons qu'il est très largement supportable, loufoque

[icer]

Personnellement, je ne vois pas pourquoi il s'agirait d'une mauvaise conception...

Après tout, la méthode UML autorise tout à fait d'y faire appel, et si on peut déconseiller dans certains d'y faire appel, c'est généralement pour la cause:

il est peut être utile de décider d'utiliser toutes les possibilités offertes par les méthodes de conception et par le langage

UML n'est pas une méthode mais un language. Dire qu'on peut le faire car UML le permet c'est dire : on peut tout faire car on peut le dire.

[bolhrak]

- Le Java ne supporte pas la sémantique de valeur aussi proprement (ou supporte pas tout court?) que le C++ ; chez lequel mélanger héritage et sémantique de valeur est suicidaire.

1] Bon c'est un point de détail par rapport au débat, mais j'ai une petite question par rapport à ça : qu'en est-il de l'héritage d'implémentation ?

Petit exemple, dans le cadre du boulot je devais implémenter deux types de courbes. La première, générale, est en gros un vecteur de point. Donc classe qui va bien avec méthodes qui vont bien (relativement nombreuses).

Le deuxième type représente une courbe pouvant être shiftée. Du point de vue concept c'est une courbe, mais qui offre des services supplémentaires. D'un point de vue utilisation, on ne l'utilisera jamais comme une courbe simple, en gros je n'aurais jamais quelque chose du style :

Code :

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

1
2
 
Curve* curve->faitUnTruc();

Avec faitUnTruc méthode non virtuelle et curve de type ShiftableCurve*. Mes courbes ne sont donc pas sensées être à sémantique d'entité. Et de mon point de vue une courbe shiftable est une courbe.

Ca me paraît donc naturel de faire hériter ShiftableCurve de Curve plutôt que d'utiliser la composition et de rediriger toutes les méthodes communes non ?

2] Deuxième question, par rapport aux évocation de contrat faites par JolyLoïc. Ma référence étant le bouquin de Bertrand Meyer, lequel affirme qu'une fonction ne devrait pas tester sa précondition. De plus je me rappelle un message (de Luc Hermite ou Jean-Marc Bourguet, dsl je ne sais plus ) affirmant que les exceptions n'étaient pas le mécanisme le plus approprié pour gérer les ruptures de contrat en C++.

D'où deux questions : est-ce que l'affirmation de Meyer (une fonction ne devrait jamais tester sa précondition) vient du fait que son langage (Eiffel) supporte nativement la programmation par contrat ? Et deuxièmement quel mécanisme préconisez-vous pour la gestion des ruptures de contrat en C++? Les assertions ?

[JolyLoic]

D'où deux questions : est-ce que l'affirmation de Meyer (une fonction ne devrait jamais tester sa précondition) vient du fait que son langage (Eiffel) supporte nativement la programmation par contrat ?

Je n'ai pas lu le livre (et je le regrette), juste quelques extraits, donc je ne sais pas quels arguments il développe. Est-ce qu'il sépare le raisonnement pour les pré et les post conditions ici ? Mais d'un point de vue, c'est bien ce qui est fait par la méthode d'interface en C++, puisque les préconditions de la fonction virtuelle privée sont vérifiée par une autre fonction, non virtuelle.

Et deuxièmement quel mécanisme préconisez-vous pour la gestion des ruptures de contrat en C++? Les assertions ?

Dans un monde parfait avec de bons tests unitaires, un mécanisme type assertions. Dans un monde bordélique, je sais pas trop.

[koala01]

UML n'est pas une méthode mais un language. Dire qu'on peut le faire car UML le permet c'est dire : on peut tout faire car on peut le dire.

Mais, à partir du moment où:

1. le langage de programmation permet quelque chose
2. le langage de conception permet cette même chose

je ne vois de toutes manières aucune raison pour décider de se passer de cette possibilité sous prétexte qu'il "faut faire attention quand on l'utilise"...

Pour moi, aucune possibilité n'est mauvaise, même si on trouve pour certaines d'autres possibilités plus efficaces...

L'héritage multiple fait partie de ces possibilités pour lesquelles il est nécessaire de réfléchir à la différence entre la plus value qu'il fournit et les risques/problèmes qu'elles impliquent.

Si le bilan est globalement positif, que les circonstances sont clairement maîtrisées et correctement étudiées, pourquoi se refuser le recours à cette technique

[Luc Hermitte]

1] Chez moi "héritage d'implémentation" ne veut pas dire grand chose -- la faute au Java qui utilise ce terme pour différencier des choses bien moins essentielles que la dichotomie que je trouve primordiale -> Je me limite à un monde simple où il n'y a que deux héritages: un de substituabilité, et un de réutilisation de code. Et après, au feeling, je compose parfois.

La question N°1 est substituabilité ou pas. Si oui, héritage public.
S'il s'agit juste de réutiliser du code, il peut m'arriver d'utiliser l'héritage privé, mais ce n'est pas nécessaire. Tout dépend de comment est prévue la classe fournissant le service, de la quantité d'appels à déléguer sans traitements préalables, de si un couplage extrêmement fort est acceptable, etc...


2] Dans ma compréhension de la PpC de Meyer, les contrats servent à "surveiller" les erreurs de programmation. Pour cela, l'outil premier est l'assertion en C++. Je vois les Tests Unitaires comme un outil secondaire qui permet de vérifier que l'on a bien la sortie attendue dans un certain nombre de cas identifiés à la main. (il permet d'autre choses comme assurer de la non régression sur ces cas, ...)

Après, quand je parlais de contrats plus haut, j'avais une vision plus large où je vais étendre le contrat à des conditions d'applicabilité dynamique. Là je vais utiliser des exceptions. Par exemple dans la fonction d'interface d'une API, je vais renvoyer une exception si un fichier ne peut être lu, ou si son contenu est corrompu. En interne, je sais que ma couche d'interface m'assure le bon état du fichier, ou des données extraites. Là, je vais partir sur des assertions car si cela cloche ensuite, c'est que je me suis planté dans mon code, ou même dans mes suppositions quant à ce que je suis censé manipuler.

Pour en revenir à l'héritage multiple de contrats, la technique portée par James, peut être utilisée aussi bien pour les contrats à la Meyer (erreurs de codage/conception/...), que pour des contrats plus "dynamiques", liés au contexte d'exécution.

Est-ce au code client, est-ce au code métier de tester les contrats? Je n'ai pas de réponse à apporter aujourd'hui : je n'ai pas suffisamment creusé la question. Pour l'instant, mon approche est pragmatique, sur des modèles de codage similaires, je factorise le mécanisme de vérification à côté du code métier.
Demain je peux très bien changer d'avis.

[Jean-Marc.Bourguet]

Ben t'as un pointeur de vtable par classe héritée, l'upcasting nécessite de réaligner, etc.

Je m'attendais a te voir proposer des alternatives. (Autrement dit etre performant n'est pas pour moi une qualite absolue mais relative).

je vais reformuler

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class A;
class B;
 
class C1
{
  A a;
  B b;
};
 
class C2 : public A, public B
{
};
 
sizeof(C1) == sizeof(C2);

- L'optimisation des classes de base vides + le fait qu'un sizeof ne retourne jamais 0 fait que l'egalite peut etre fausse;

[ac_wingless]

On ne peut pas dire que le besoin d'héritage multiple soit courant, mais il existe ici ou là. Ne pas l'avoir à sa disposition peut donc être préjudiciable et aboutir à du code suboptimal, dans ces cas précis et légitimes.
Quant il n'est pas utilisé, il n'a aucun cout (comme toujours en C++).
Quant il est mal utilisé, ben il est mal utilisé, et c'est Mal. Là aussi c'est assez typique du C++, mais c'est un autre débat.
Si j'avais quelque chose à reprocher à cette fonctionnalité en C++, ce serait plutôt au niveau des détails d'implémentation dans les cas non triviaux (héritage virtual, ordre d'initialisation dans les arborescences) que du principe. Certaines utilisations historiques, maintenant heureusement obsolètes, comme l'ajout de traits à un type, ont été avantageusement remplacés par l'utilisation de templates. Donc l'état actuel de l'héritage multiple en C++ me parait tout à fait satisfaisant.

[screetch]

- L'optimisation des classes de base vides + le fait qu'un sizeof ne retourne jamais 0 fait que l'egalite peut etre fausse;

c'est un peu du chipotage la. il y a de fortes chances que les classes de bases ne soient pas vides puisqu'elles contiennent surement une vtable.

[zabibof]

Personnellement, je ne vois pas pourquoi je serais contre l'héritage multiple et je ne vois pas pourquoi ce serait un problème de conception, le seul inconvénient, c'est la taille du vtable.

[loufoque]

Je m'attendais a te voir proposer des alternatives.

Une alternative, c'est les concepts.
Quand tu déclares une classe, tu fais une assertion qu'elle vérifie les concepts C1...Cn.
Tu peux toujours référencer ton objet par un "pointeur" vers l'interface/concept avec un truc comme adobe::poly.

Le problème étant que des trucs comme adobe::poly ça reste pas terrible, l'idéal ce serait que le langage aide.
Et pour les assertions, je crois pas qu'on puisse les faire à la compilation (quoique avec les constexpr peut-être).

[Jean-Marc.Bourguet]

Une alternative, c'est les concepts.

Ou j'ai manque quelque chose dans l'evolution du langage, ou les concepts sont qqch de
statique et j'ai du mal a les considerer comme une alternative a toutes les utilisations de l'heritage multiple. Si tu cherches des alternatives partielles, il y a aussi le CRTP qui permet de lineariser certains cas ou l'heritage multiple est aussi envisageable.

[Feriaman]

Et pour les assertions, je crois pas qu'on puisse les faire à la compilation (quoique avec les constexpr peut-être).

J'ai bien tout lu le topic (ouf), et je ne suis toujours pas sur du sens de cette phrase.

Ce qui est sur c'est que l'on peut faire des assertions à la compilation en C++ ça s'appelle des asserts statiques. Mais dans la mesure où je n'ai pas bien compris ta phrase, il est possible que cela ne contredise pas ce que tu viens de dire.

Quant à savoir si on doit autoriser les héritages multiples, à mon avis, la réponse est "oui", par contre il faudrait interdire aux gens qui s'en servent de coder sur les mêmes projets que moi.

Plus sérieusement, il me parait clair, suite à cette discussion (et aux nombreuses autres sur le sujet) que c'est un concept délicat, et ceci :
- parce que parfois on ne peut pas faire mieux
- parce que souvent on s'en sert n'importe comment

Donc utilisons les héritages multiples, mais avec parcimonie et méfiance.

[loufoque]

Ou j'ai manque quelque chose dans l'evolution du langage, ou les concepts sont qqch de
statique et j'ai du mal a les considerer comme une alternative a toutes les utilisations de l'heritage multiple.

le principe de adobe::poly, que j'ai cité, c'est de faire des trucs qui ressemblent aux concepts avec du dynamic dispatch.
C'était un élément alternatif aux interfaces, pas à l'héritage multiple en général.

J'ai bien tout lu le topic (ouf), et je ne suis toujours pas sur du sens de cette phrase.

Ce qui est sur c'est que l'on peut faire des assertions à la compilation en C++ ça s'appelle des asserts statiques. Mais dans la mesure où je n'ai pas bien compris ta phrase, il est possible que cela ne contredise pas ce que tu viens de dire.

Je parlais de faire l'assertion qu'une classe implémente un concept...

[Feriaman]

Je parlais de faire l'assertion qu'une classe implémente un concept...

Dans ce cas désolé .. je me disais bien aussi que j'avais du mal comprendre quelque chose.

Bonne soirée.

[bolhrak]

@Luc Hermitte : merci pour ces précisions. Effectivement le terme "implémentation" était mal choisi de ma part, il s'agirait plus d'héritage d'extension (donc pas de substitualité ici).

@JolyLoïc : effectivement il traite les cas préconditions et post conditions différemment, il considère qu'une précondition de méthode peut/doit être vérifiée par le code client et non dans l'implémentation de la méthode.