Bonjour, 

Sa fait un petit moment que j'essaye de faire des choses avec Unity. Problème, c'est que lors de la conception de l'orienté objet, je me retrouve face à un problème. J'aimerai extends une classe (ex: RaceJouable qui extends Humain), mais le problème est que cette classe est déjà extends par Monobehavior.

Mon problème est donc comment extends une classe tout en gardant les fonctionnalités proposé par la classe Monobehavior?

J'ai un peu fouillé mais je ne suis tombé que sur des techniques qui ne me conviennent pas. Du genre à la place de faire une classe qui extends, faire une interface qui implements. Un magicien pour trouver une solution à ce dilemme qui me ronge depuis plusieurs mois? 

Généralement, sous Unity, l'approche POO brute des années 80/90 montre très vite ces limites.

Unity est conçu pour l'utilisation d'une approche ECS, bien plus flexible pour les types d'applications ciblées par le moteur (Jeu, CAO, etc ...).

L'API offerte par Unity s'en ressent dans ce domaine.

Une approche POO "orthodoxe" dans un jeu entraine très souvent une arborescence de classe bien trop profonde, bien trop complexe à maintenir par rapport à l'utilisation intelligente d'une approche ECS.

Dans votre exemple, il y a déjà de gros problèmes de conception dès l'usage des noms.

Au sens RPG, Humain est une Race, donc faire dériver "RaceJouable" de "Humain" => vous ne pouvez jouer que des humains dans votre RPG.

C'est vraiment très très limite.

Dans une approche ECS, on va rendre l'aspect "RaceJouable" et "Humain" orthogonal.

Ainsi, tout "GameObject" pourra avoir le comportement implémenté par "RaceJouable".

Si vous voulez que le "GameObject" implémente une API pour que votre implémentation de "RaceJouable" fonctionne, utilisez l'Attribut .NET "RequiredComponent" ( https://docs.unity3d.com/ScriptReference/RequireComponent.html ).

L'héritage est vraiment la liaison la plus forte en POO et on lui préfère toujours d'autres solutions plus flexibles, comme la composition, lorsque la conception ne la requière pas explicitement.

(Vous pouvez toujours remplacer Monobehavior par votre classe mère, mais c'est très très rarement une bonne solution).

Posez-vous la question 'Pourquoi un "RaceJouable" devrait être toujours utilisable dans tous les codes qui acceptent un "Humain" ?', je ne suis pas sûr que cela soit si évident et si flexible que cela.

Je pense avoir trouvé mon magicien . Merci beaucoup pour cette explication claire. Je ne comprend pas encore tout les éléments de ta réponse, mais tu as bien répondu à mon problème. Plus qu'à se retrousser les manches et fouiller un peu sur internet pour comprendre les éléments incompris. Merci encore, surtout que la réponse à dû prendre pas mal de temps . Je clos le sujet