Pour être clair, je ne demande pas si / pourquoi la héritage multiple est bonne ou mauvaise. J'ai entendu beaucoup d'arguments des deux côtés de ce débat.
Je me demande s'il y a une sorte de problème de conception ou de scénario en C ++ dans lequel de multiples héritages est le seul moyen d'accomplir quelque chose ou du moins est le moyen le plus optimal sur toutes les autres alternatives au point que ce soit 't donner un sens à considérer autre chose.
Évidemment, cette question ne s'applique pas aux langues qui ne prennent pas en charge plusieurs héritages.
10 Réponses :
Vous ne pouvez pas faire Conception basée sur les stratégies sans héritage multiple. Donc, si la conception basée sur les stratégies est le moyen le plus élégant de résoudre votre problème, que cela signifie que vous avez besoin de multiples héritage pour résoudre votre problème, sur toutes les autres options.
Héritage multiple peut être très utile s'il n'est pas mal utilisé (comme tout, dans n'importe quelle langue).
Cela impliquerait-il que la conception basée sur les politiques n'était tout simplement pas possible dans une langue telle que Java, ou existe-t-il des moyens de travailler autour de lui?
En réalité, l'article lié indique que plusieurs héritages ne sont que le schéma de mise en œuvre le plus courant (avec quelques avantages significatifs), et non qu'il est absolument nécessaire.
@Jeff l: la classe "proxy" en Java peut être utilisée comme solution de contournement.
Pas dans la manière dont la conception basée sur les politiques fonctionne généralement, non, je ne pense pas que Java puisse le faire. Il pourrait être en mesure de faire l'alternative, où il existe des variables de membre pour chaque politique plutôt que de en héritage, mais cela perd certains avantages héritariants. Si Java peut utiliser des modèles comme celui-ci du tout, je ne sais pas.
@Gman: Avec un peu de chaudière en Java, vous pouvez simplement déléguer des méthodes connues au moment du codage (d'où tout l'hôte appelle en réalité les appels d'hôte) aux objets de politique et avoir des accesseurs pour eux. Dans la version C ++, l'hôte élargit automatiquement son interface pour inclure des fonctions arbitraires souhaitées par l'utilisateur et regroupées dans leurs classes de mixine. Je suppose donc que cela dépend si vous êtes (ou bien, Alexandrescu) considérez cette fonctionnalité de séparation du «modèle de politique» en tant que telle, ou une partie intrinsèque de celui-ci. En Java, vous pouvez toujours permettre aux utilisateurs de récupérer les objets de la stratégie, le refuge et l'appel.
Vous pouvez également faire une conception basée sur des stratégies sans MI assez facilement dans des langues prenant en charge les macros, par exemple. Lisp ou clojure
Il y a une situation dans laquelle vous hériteriez d'une classe et peut-être implémenter une ou deux interfaces en Java. C'est quelque chose que vous résolvez avec plusieurs héritage en C ++, je pense.
J'aurais suivi sur des interfaces Java, etc., pour avoir une meilleure idée de la réponse à cette question. L'idée derrière une interface est de créer une classe abstraite qui agit comme un modèle pour une autre classe. L'avantage, ici, c'est que les modèles peuvent être combinés dans une classe de béton. Par exemple -
Classe des parents- Foodstore Sous-classe - Coffeeshop Sous-classe - Boulangerie
Avec cet arbre de héritage, une alimentation peut être une boulangerie ou une cafetière mais pas à la fois. Mais alors que ferions-nous un starbucks?
meilleur moyen, imo -
Classe des parents- Foodstore Interface-Coffeeshop Interface-boulangerie
La classe publique Starbucks étend des outils de produits de goodstore, la boulangerie {...}
Vous devrez connaître un peu de Java pour comprendre cela, mais en avoir. Les interfaces sont assez élémentaires, imo.
En tant que suspension supplémentaire, les interfaces sont peut-être conçues pour obéir "Ne pas répéter toi-même". Évident, maintenant que je le mentionne.
Héritage multiple est utile si vous devez hériter comportement , pas seulement contrat . Toutefois, comme les autres langues démontrent, une héritage multiple n'est pas la seule façon de résoudre ce problème, au détriment de rendre votre arbre d'héritage plus profond. En tant que tel, des scénarios où vous
Comme on autant été dit sur les autres réponses:
à l'aide de classes de base virtuelles pures comme "interfaces", comme dans Java ( http://fr.wikipedia.org/wiki/interface_ (Java) ), c'est un oo très courant modèle dans tous les o.o. Langues, non seulement Java
faire des conceptions basées sur la police
mais aussi:
C ++ Les flux utilisent plusieurs héritions: C'est la seule solution "raisonnable" en ce sens qu'il serait déraisonnable que les flux font partie des bibliothèques standard prennent la même ligne que les algorithmes et les collections. Donc, OneTream se comporte polymorphiquement plutôt que d'être une interface "dactylographie de canard" comme Itérateur (*).
Dès que vous avez un polymorphisme dynamique, vous avez besoin de multiples héritage pour mettre en œuvre plusieurs interfaces en même temps.
(*) Vraisemblablement, c'est parce que toute autre chose serait une ruine. Vous devez être capable d'écrire des fonctions réelles qui manipulent des flux, plutôt que de forcer les utilisateurs à avoir des modèles partout. C'est parce qu'il est courant d'écrire à "un ruisseau, je ne sais pas ce que tant que ce soit à l'exécution", mais de ne pas vouloir manipuler "une certaine collection, je ne sais pas ce que tant que le temps d'exécution". Istream et ostream sont les deux parents de iostream . Depuis qu'ils héritent de ios_base , vous avez un diamant.
Lorsque vous souhaitez hériter des fonctionnalités plutôt que du rôle, un cas dans le point Boost :: Non géré (autres langues qui supportent ceci (contrairement à Java et C #) appellent ceci a mixin ).
Lorsque vous devez combiner deux ou plusieurs hiérarchies de classe tiers, chacune d'elles nécessite que les objets soient dérivés de la propre classe de base de la hiérarchie, il ne manquera pas de multiples héritage rendra votre code complexe et fiddleux.
class ReflectivePickle :
public Object_Database::Object,
public Reflectives::Object {
// ...
};
J'ai tendance à utiliser plusieurs héritage dans C ++ lorsque les classes de base sont "classes d'interface", c'est-à-dire des classes de base où toutes les méthodes sont pure virtuelle, aucune mise en œuvre [N'oubliez pas que vous pouvez toujours définir une implémentation, mais vous devez toujours l'invoquer explicitement. ], et il n'y a pas de membres de données. Très similaire à "interfaces" en Java ou (de ce que j'entends) C #.
Pour utiliser le polymorphisme en C ++, vous ne pouvez pas utiliser la composition, vous devez utiliser (public) héritage.
Donc, si la barre de classe hérite (publiquement) à partir d'imprimable et sérialisable, je peux traiter l'objet comme un objet imprimable, un objet sérialisable ou un objet bar (à l'aide de pointeurs ou de références).
Avec la composition, vous ne pouvez pas faire cela.
Si vous voulez voir une belle mise en œuvre de multiples héritage, vérifiez Eiffel. Ils résolvent le problème de diamant par le renommage de la fonctionnalité, plus simples que la résolution de la portée et il prend même en charge une héritage répétée directe telle que:
Un hériter B, B, B
Lorsque le besoin survient à utiliser ce type d'héritage.
Leur bibliothèque de noyau est open source et multiple héritage est largement utilisé si vous souhaitez voir des exemples.
Une question similaire: Stackoverflow.com/Questtions/573913/...