Discussion :

[vodosiossbaas]

bonjour , j'aimerais savoir , étant débutant , si vous utilisez l'héritage multiple souvent ou est-ce que vous considérez que ce n'est pas une fonctionalité utile.

[Kaktus]

N'oublie pas que les MFC sont truffés d'héritages multiples qui fonctionnent bien, donc c'est que c'est utile .


Personnellement je ne l'utilise seulement que si les deux classes parentes n'ont pas d'attributs communs pour éviter toute déclaration virtuelle qui, faut bien le dire, met un bazar certain.
Je pense qu'il faut être vraiment calé (ce qui n'est pas mon cas) avant de l'utiliser sans problèmes.


La plupart du temps, on peut s'en sortir sans, en utilisant notamment les agrégations (une classe contient des objets d'autres classes dans ses membres).

Voilà .

[vodosiossbaas]

merci pour ta réponse , mais tu peux remarquer que en java , l'héritage multiple est désactivé et java est un langage stable et puissant .
tu ne crois pas que l'heritage multiple nuit à la simplicité des programmes et qu'il peut amener des bugs ?

[Caine]

Bonjour,
Il ne suffit pas d'éviter d'utiliser l'héritage Multiple pour éviter les bugs.

Utiliser n'importe quelle fonctionnnalité objet sans discernement amènera des bugs

Pour l'héritage Multiple, il pose un problème certain avec la dérivation:

La dérivabilité devient critique avec des classes multiples, en raison des références croisées, de la cohérence des objets ...

Par contre, pourquoi les utiliser? Ca permet à la classe amie d'utiliser l'intégralité de l'autre classe, y compris ce qui est private et protected donc un gain de temps et parfois de lisibilité.

[Kaktus]

pour Java, oui et non.
On ne peut certes pas faire d'héritage multiples mais on peut implémenter plusieurs interfaces.

Or, qu'est-ce-qu'une interface? Une classe avec des fonctions virtuelles pures uniquement à redéfinir bien sûr dans les classes filles.
Le mot "interface" est inconnu en C++, mais rien n'empêche de programmer comme en Java.


Sincèrement, je pense que l'héritage multiple est une bonne idée, seulement, comme beaucoup d'outils puissants du C++ (surcharge d'opérateurs entre autres ...) il faut les utiliser d'une façon intelligente,compréhensible et bien maîtriser le sujet (sic).

Pour mon jeu, j'ai fait par exemple une classe CSprite (affichage/déplacement d'images), une classe CEvent qui gère les évênement type souris/ clavier.
Il m'a semblé logique de faire une classe CPlayer dérivant de CSprite et de CEvent, montrant qu'un objet issu de CPlayer se doit d'afficher et de gérer les évênements.



Voici un mauvais exemple d'héritage multiple (à mon avis) :

Supposons que l'on veuille recenser les rôles du personnel de la Sécu.
On trouve des secrétaires, des comptables, des stagiaires.
L'idée est donc de faire des classes dérivées d'une classe Personnel (comme attribut, on peut mettre le nom, numéro etc..)

class Secrétaire : public Personnel,
class Comptable: public Personnel,
class Stagiaire : public Pesronnel,

Que se passe-t'il si un secrétaire est comptable aussi ? Ben avec cette logique, tu es obligé de faire un héritage multiple avec les "virtual" qui vont bien. Jusque là, ça va encore.
Et si maintenant un stagiaire est secrétaire et comptable?
Ben t'es dans la panade.

Tu imagines qu'on peut aller très loin dans le raisonnement, donc ce cas, rajouter des rôles rend le programme infernal à maintenir.


Je ferais plutôt ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
// Classe abstraite
class Rôle {};
 
class Secrétaire : public Rôle {};
class Comptable : public Rôle {};
class Stagiaire : public Rôle {};
 
// Et :
class Personnel {
 
        protected :
        list<Rôle*> lrôle; };

Ca c'est pour montrer que l'héritage multiple ne doit pas être utilisé partout. Il peut se concevoir dans des modèles verrouillés (pas d'ajout de classe) et lorsque la classe fille hérite vraiment des deux classes mères.
(dans ce cas, dire qu'une personne hérite d'un ou deux rôles, bobof sauf si tu dors dans ton bureau ).




Maintenant cet exemple, où là, je ne vois pas comment faire sans héritage multiple.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
class Telephone {};
 
class Ordinateur {};
 
class Portable {};
 
class TelephonePortable : public Telephone,virtual public Portable {};
 
class OrdinateurPortable : public Ordinateur,virtual public Portable {};
 
class LaTotale : public TelephonePortable, public OrdinateurPortable {};

Sauf erreur de ma part (comme quoi, c pas gagné la super maîtrise ), ça devrait marcher.




Comme tu le vois, c'est surtout selon . Probablement que d'autres programmeurs voient une solution différente.

Bon sujet en tout cas....

[Troll]

Evidement que l'héritage multiple est utile, et même indispensable.
N'importe quel développeur qui réalise des projets conséquents en utilisant plusieurs API externe, rencontre cette nécessité (notamment pour implémenter des interfaces).

Il ne faut pas avoir peur de l'héritage multiple, ce n'est pas une erreur de conception (comme on l'apprend parfois à l'école) .
On peut toujours faire sans. Mais à quel prix ? Et pour quel gain ?

Je rejoint Kaktus pour dire qu'il faut juste maîtriser un minimum le sujet pour éviter les pièges, mais c'est souvent comme ça avec le C++.

Donc si tu es débutant, documente toi un peu avant de te lancer.

[BertrandA]

N'oublie pas que les MFC sont truffés d'héritages multiples qui fonctionnent bien, donc c'est que c'est utile

Non il n'y a aucun héritage multiple dans les MFC.
Si mes souvenirs sont bons, c'est le cas en revanche dans OWL.
Les MFC sont d'ailleurs relativement pauvres au niveau des concepts objets : pas d'espaces de noms, conteneurs propres, des macros au kilomètre, modèle pas vraiment MVC...

[Gandalf]

Ce n'est pas parce que l'héritage multiple est utile qu'il faut en coller partout...

De même, ce n'est pas parce qu'il ne faut pas en coller partout que c'est inutile...

[Luc Hermitte]

merci pour ta réponse , mais tu peux remarquer que en java , l'héritage multiple est désactivé et java est un langage stable et puissant .
tu ne crois pas que l'heritage multiple nuit à la simplicité des programmes et qu'il peut amener des bugs ?

Hum....
Java permet une forme dégradée d'héritage multiple comme cela a été signalé.
Le C++ va plus loin en permettant de rajouter les contraintes au milieu -- Java demande l'utilisation d'un outil externe pour obtenir le même niveau de "sécurité". (Eiffel, D et quelques autres ont un support natif et encore plus transparent de la gestion de contraintes).

Il y a quelques autres cas où avoir un héritage multiple devient intéressant. Notament quand on veut combiner plusieurs interfaces avec plusieurs implémentations (des interfaces) par défaut ou non. C'est un peu ce que l'on retrouve en Corba ou avec COM-ATL.
L'approche Java va demander une délégation explicite et donc plus de verbosité -- on peut passer par un outil qui va générer automatiquement du code afin de limiter les risques de copier-coller foirés.

C++ offre le choix. Java considère que l'on n'est pas assez doués pour l'avoir, ou croit honnêtement que cela ne sert vraiment à rien, je ne sais trop le pourquoi du comment de leurs choix.

Maintenant il est vrai qu'il ne faut pas utiliser l'héritage multiple à tord et à travers. Les quelques cas où l'on va considérer son utilisation sont assez bien connus/récurrents -- une fois initiés... Ce qui fait que l'on peut parfaitement d'en servir sans risques tant que l'on reste dans les sentiers battus.
On peut aussi faire n'importe quoi. Et malheureusement, le n'importe quoi n'est pas rare du tout, loin de là.


Il me semblait avoir lu de la prose de Loïc à ce sujet il y a peu. Je me trompe ?

@ Kaktus. Pour ton dernier exemple, on peut jouer avec Mixin-classes et autres polices pour composer les classes d'implémentation finales qui pourront répondre à une interface ou divers ensembles d'interfaces. On aura toujours de l'héritage multiple (avec l'approche "polices"), mais peut-être pas de l'héritage en diamant.