L'héritage multiple (MI) est un concept de programmation qui permet à une classe d'hériter de plusieurs classes parents. Bien que cela puisse sembler un moyen pratique de combiner des fonctionnalités, cela peut souvent conduire à des cauchemars de maintenance.
1. Composition plutôt que héritage :
Envisagez d'utiliser la composition au lieu de l'héritage lorsque cela est possible. La composition vous permet de combiner des objets avec différentes fonctionnalités sans encourir les complexités du MI.
2. Le Diamant de l'effroi :
MI peut créer le scénario "Diamant de l'effroi", dans lequel une classe hérite de deux classes qui héritent d'un ancêtre commun. Cela peut conduire à des ambiguïtés et des conflits dans la résolution des méthodes.
3. Ambiguïté avec l'héritage virtuel :
Dans les hiérarchies d'objets, le graphe d'héritage devrait idéalement être un arbre, pas un graphe. MI peut introduire une ambiguïté lors de l'héritage de plusieurs interfaces partageant des méthodes similaires.
Malgré ses inconvénients, MI peut être approprié dans certains scénarios :
1. Classes non liées :
Si les classes en question ne sont absolument pas liées et servent des objectifs distincts, alors MI peut simplifier la mise en œuvre.
2. Héritage privé :
L'héritage privé peut être utilisé pour mettre en œuvre les détails de mise en œuvre sans les exposer publiquement, réduisant ainsi les risques associés à MI.
3. Idiomes C :
Certains idiomes C, tels que les politiques, utilisent l'IM pour atteindre des objectifs de conception spécifiques.
Bien que l'IM puisse être une option pratique, il doit être utilisé avec prudence. La plupart du temps, la composition ou l’héritage unique est préféré pour éviter les complexités et les pièges associés à l’IM. Soyez prêt à défendre votre utilisation de MI lors des révisions de code et envisagez des approches alternatives chaque fois que possible.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!