Implémenter un truc proprement, sans héritage multiple

Salutations,

Je suis confronté à un petit problème avec une situation qui me semble taillée pour de l'héritage multiple, sauf qu'évidemment la chose n'est pas permise en C#. Aussi je me demandais si quelqu'un aurait une idée pour contourner la chose aussi proprement que possible. Détail du problème :

Je travaille actuellement sur un moteur de jeu de scrolling 3d isometrique permettant d'afficher des mondes comparables à ce qu'on peut voir sur Roller Coaster Tycoon : un terrain composé de différentes Tiles donc.

A l'heure actuelle, le moteur graphique est bien avancé et je commence à me poser des questions concernant le code réseau : je souhaite développer un jeu pouvant se jouer à plusieurs selon une architecture client serveur classique.

Histoire de faire les choses proprement, l'idéal serait que le programme serveur n'ait pas à se soucier des composantes graphiques du jeu, et même qu'il ignore jusqu'à l'existence de XNA.

Pour ce faire, je souhaite donc partage ma classe Tile initiale en deux classes : Tile (nouvelle) utilisée à la fois par le client et le serveur, qui contient les informations logiques de la tile en question : sa hauteur, son type, les trucs relatifs aux collisions etc... et TileSprite, qui contient tout ce qui est relatif à l'affichage (apparence de la tile (Sprite), offsets pour l'affichage, etc etc...) qui sera donc utilisé par le client.

Tile est une classe abstraite de laquelle héritent mes tiles concrètes : tile de sol classique, de pente, de coin etc etc..., chaque fille spécifiant les comportement propres (pour les collisions par exemple), mais reprenant des attributs et méthodes de la mère (hauteur de la tile par exemple, accesseurs).

Idem, TileSprite est une classe abstraite de laquelle héritent mes TileSPrite concrètent, qui spécifient le comportement des fonctions de détection d'hovering de la souris, les offsets d'affichage, les positions pour les décros etc...)

Or, idéalement, la TileSprite fille correspondant à une Tile de coin par exemple, devrait hériter à la fois de la Tile de coin (pour sa logique) et de TileSprite (pour l'affichage).

Sauf que bien sûr ca n'est pas possible... Et la je vois pas trop comment faire proprement.

La solution que j'utilise pour l'instant, c'est que mes TileSprites concrètes héritent seulement de TileSprite et possèdent un attribut de Tile (concrète), mais... je trouve ca plutôt moche...

Résumé si vous êtes perdus :

Tile (abstraite, logique d'une tile), de laquelle hérite une Tile concrète TileCoin (par exemple)
TileSprite (abstraite, affichage d'une tile), de laquelle hérite TileCoinSprite (par exemple)

Sauf que TileCoinSprite devrait aussi hériter de TileCoin (si jamais je veux utiliser des mécanismes de prédiction coté client par ex : il faut aussi que j'ai accès à la logique coté client)

Voila, si quelqu'un a une idée :s

Merci d'avance.

Et pour ceux que ca intéresse : [ame="http://www.youtube.com/watch?v=qitkgiP13gw"]YouTube- Isometric1[/ame] (le moteur en question, en l'état actuel)

salut

pour palier à l'héritage multiple, tu peux utiliser les interfaces qui sont des contrats permettant de définir les règles qu'implémente une classe.

Celà me semble le plus "simple".

Effectivement, l'utilisation des interfaces est un bon compromis.
Sinon, tu peux aussi voir du côté du pattern decorator. Je pense qu'il y a un truc à faire avec ça.

Oui, ou de passer par :
- une classe par classe parent,
- l'enfant dispose de propriétés présentant les instances des parents,
(style strategie)

Salut,

tu rentres parfaitement dans le cadre d'utilisation des interfaces. Tu peux même implémenter des corps de méthodes pour chaque interface grâce aux méthodes d'extension C#.

Merci pour les réponses, mais les interfaces ne résolvent pas mon poblème puisqu'elles ne me permettent pas de définir des attributs (Or Tile et TileSprite comportent toutes les deux des attributs qui sont propres à leur descendants respectifs : je ne me contente pas de définir l'interface de ces classes, je défini aussi partiellement les propriétés).

MetalGeek, je savais pas que je pouvais implémenter le code de certaines de mes fonctions au sein d'une interface, mais ca me semble un peu bizarre puisque cela impliquerait les même problèmes que ceux posés par l'héritage multiple.

Pour reprendre ce qui a été dit : certes le problème correspond exactement au cas de l'utilisation d'interfaces (avec des classes implémentant plusieurs (2 en l'occurence) interface), sauf qu'il faut que les dites interfaces possèdent des attributs (des variables donc) et spécifient certaines de leur méthode. Et ca ca s'appelle l'héritage multiple avec des classes.

Sinon, tu peux faire hériter des types de System.Windows.DependencyObject, et utiliser des propriétés de dépendance attachées pour régler le problème des 'attributs' à définir. Tu gardes aussi les interfaces, et les méthodes d'extension pour implémenter les méthodes.

Citation:

---

Envoyé par syntaxerror

Merci pour les réponses, mais les interfaces ne résolvent pas mon poblème puisqu'elles ne me permettent pas de définir des attributs (Or Tile et TileSprite comportent toutes les deux des attributs qui sont propres à leur descendants respectifs : je ne me contente pas de définir l'interface de ces classes, je défini aussi partiellement les propriétés).

---

Intéressant, j'ai eu récemment le même type de problème. On m'a expliqué que de manière générale, on a tendance à sur-utiliser l'héritage de classes pour ajouter du contenu (pour "récupérer/réutiliser" des propriétés typiquement). Tout ça, apparemment, parce qu'on ne fait pas la distinction entre un ajout de données et une modification de comportement. L'héritage de classes ne devrait être utilisé que pour garantir un comportement, pas des données. Pour les données il faudrait préférer la composition. Je dis ça mais j'ai toujours encore le même réflexe que toi.
Vois avec le pattern decorator comme l'as dit oyigit. Avec ça tu pourras rajouter des fonctionnalités qui ont l'air d'être "héritées". Et pour les données, une relation de composition. On peut faire plein de choses avace la composition qu'on ne soupçonne même pas.
Sinon, si tu cherches sous "inheritance vs composition" tu trouveras plein de littérature.

Ou pire, certains se demandent s'il ne faut pas interdire l'héritage de classes.

Sinon, aussi, pour ton problème d'interface incapable de définir des attributs... Elles sont capables de définir des propriétés. Tu utilises des attributs visible en externe?

Ce qui me choque, surtout, c'est que tu veuilles faire hériter un objet d'UI d'un objet métier... Donc je verrais plutôt deux hiérarchies de classes en parallèle, l'une métier, l'autre UI, avec de la composition pour relier ces deux univers.

Ou sinon, si ton appli n'est pas censée être transformée tous les 3 mois, tu laisses tomber les 'best practices' qui te font te sentir bien dans le domaine de la théorie, et tu fais 2 ou 3 copiés collés qui te sauvent la vie dans le monde réel.

@MetalGeek: tout mais pas le copier/coller :ouin:!!! Je travaille sur un soft où il traine du copier/coller. Dès que tu veux modifier un truc c'est galère!!! Surtout qu'au fur et à mesure, le copier/coller évolue en un OGM (objet génétiquement modifié) mutant !! Si ça restait exactement le même code, ça resterait possible. Mais vu que le code évolue qd même sournoisement petit à petit (la partie copiée et la partie collée), ensuite c'est difficile de recouper...

Proverbe perso employé dans ma boite... : copie/coller c'est le maaaaaaaaaaaaaaaaal :mouarf: