L'héritage multiple ne résout-il pas tous les problèmes posés par les systèmes d'entités?

La question est assez explicite: l'héritage multiple ne résout-il pas tous les problèmes que les systèmes d'entités résolvent également?

Je viens de me souvenir d'un terme appelé "héritage multiple", et cela semble résoudre beaucoup de problèmes de ballonnement qu'imposait l'héritage classique.

— jcora
source

L'héritage multiple est similaire aux systèmes d'entités, mais ce n'est pas la même chose. Par exemple, plusieurs entités d'héritage ne peuvent pas avoir de composants ajoutés et supprimés au moment de l'exécution. Toutes les langues ne prennent pas en charge l'héritage multiple non plus. Vous pouvez également considérer que la composition appartient à la même catégorie que l'entité / les composants.

— MichaelHouse

Si vos classes sont déjà si soignées que vous pouvez les hériter de manière transparente de la manière qui vous convient, elles pourraient aussi bien être déjà des composants. Les composants permettent également la composition / agrégation lors de l'exécution

Eh bien, c'est plus complexe et moins sujet aux erreurs, alors pourquoi le préférer?

— API-Beast

MI ne traite pas non plus vraiment les problèmes de "ballonnement", car hériter d'un excès d'interface d'une classe ou de classes parentes est plus un symptôme d'une mauvaise utilisation d'un mécanisme d'héritage plutôt que d'un héritage simple ou multiple. Le même "ballonnement" peut également être obtenu dans une approche orientée composition d'un problème.

@MrBeast voulez-vous dire plus complexe / plus sujet aux erreurs, moins complexe / sujet aux erreurs, ou "pourquoi ne pas le préférer?"

— 3Dave

Réponses:

Non, l'héritage multiple ne résout pas tous les mêmes problèmes que les systèmes d'entités: les systèmes d'entités et l'héritage multiple sont deux choses très différentes. Vous pouvez créer un système d'entités avec ou sans héritage multiple et, de la même manière, vous pouvez utiliser l'héritage multiple sans créer de système d'entités.

Traditionnellement, les systèmes d'entités axés sur les composants sont développés en raison d'un désir de s'éloigner de l'héritage lourd sous quelque forme que ce soit, visant plutôt la composition . Il y a suffisamment de littérature et de discussion ailleurs sur cet adage, par exemple sur les programmeurs SE ou SO lui - même , et la question plus large de savoir pourquoi préférer la composition est en quelque sorte hors sujet pour le développement de jeux. En bref, cependant, c'est une approche qui tend à se prêter à une mutabilité et une maintenabilité améliorées.

— Communauté
source

La réponse de Josh est impressionnante, mais j'aimerais ajouter:

L'une des fonctionnalités les plus intéressantes d'Entity / Component est la manière basée sur les données de créer et de gérer chaque "chose" dans votre jeu. D'après ce que j'ai vu, une fois que vous avez créé une belle bibliothèque de types de composants et de systèmes, vous pouvez construire à peu près n'importe quoi avec un minimum de modifications de code. (Remarque: minime! = 0 )

En définissant votre jeu en termes de comportement et en vous donnant la possibilité de modifier ces comportements à la volée - lors de l'exécution, lors de l'initialisation en les chargeant à partir d'un script ou d'une base de données, etc. - vous ouvrez un monde entier de nouvelles possibilités. Vous voulez voir pourquoi vos ombres ne se posent pas là où vous vous attendez? Ajoutez un composant caméra / POV à votre lumière.

L'entité / le composant vous permet de créer tout ce que vous voulez, tant que vous avez créé les blocs.

De plus, l'héritage multiple pose le même problème que l'héritage simple. Lorsque vous ajoutez un attribut ou un comportement dans la hiérarchie, il se propage. Tant que vous créez des hiérarchies profondes, vous rencontrerez des situations où vous portez un poids inutile, dupliquez du code ou résolvez des conflits. La plupart de cela peut être évité lorsque vous imaginez votre jeu comme des données.

Je viens de commencer à jouer avec ça au cours des dernières semaines, mais je suis impressionné par la simplicité des choses. Ce n'est pas une solution miracle - j'ai rencontré quelques cas où attacher un lambda à un composant était le moyen le plus propre et le plus rapide de résoudre un problème - mais c'est un très bon modèle, si vous pouvez l'appeler ainsi.

Sur une note légèrement liée: l'un des grands générateurs de maintenance ennuyeux dans les applications centrées sur les données (sites Web, etc.) consiste à mapper des objets hiérarchiques dans des bases de données relationnelles. Nous avons beaucoup de solutions astucieuses, mais elles sont finalement toutes des hacks conçues pour aplatir les hiérarchies. Au lieu de construire votre modèle pour qu'il serve l'objectif de l'application, vous finissez par faire un compromis entre une hiérarchie efficace et une représentation relationnelle logique. J'ai joué avec l'idée de reconstruire une assez grande hiérarchie dans l'une de mes applications en tant que système d'entité / de composant - abandonner la hiérarchie et faire de la base de données l'étalon-or pour le reste de la mise en œuvre - et c'est prometteur.

Lorsque vous intégrez des fonctionnalités telles que la génération de code dynamique / la mise en cache de code qui peuvent résoudre les problèmes de performances, vous vous retrouvez avec une architecture logique rapide, flexible qui pourrait simplement réaliser l'objectif de code réutilisable de la POO d'une manière beaucoup, bien meilleure.

— 3Dave
source