Discussion :

[TheDrev]

Bonjour,
J'essaye de faire un petit jeu, et je commence sous UML pour toute la conception. Je connais bien la theorie mais j'ai du mal a implementer tout ca concretement.

concrètement, j'ai des classes metier qui ne seront jamais affiché, et d'autres "graphique" qui le seront (exemple : un jeu de dès, une classe calculateur métier et des classes dès ou le plateau).

J'essaye de trouver une conception elegante a ce problème. Pour le moment j 'ai crée une classe abstraite "element graphique" avec comme attribue la coordonnée a l'écran, et une méthode "afficher".

Le problème c'est que beaucoup de classes doivent heriter, et cette methode bien que fonctionelle me parait coneptuellement douteuse (Melange complet des classes metier et affichage, fleches qui vont vraiments dans tout les sens)
Faut il plusieurs diagrammes ? Doit-je passer par des interfaces, les implementer dans chaques classes dites graphiques ? Dans ce cas, je devrais faire des classes abstraites pure si je choisi C++ et re-implementer les methode dans ces classes graphique ?

[ego]

Tu as raison de douter de ta conception car il y a effectivement risque de mélange "métier - graphique".
Quand on veut représenter des objets métier de manière graphique, on créé en général des objets graphiques dédiés à l'affichage d'objets métier et on ne donne pas la responsabilité à l'objet métier de savoir s'afficher (pas de méthode afficher dans l'objet métier).
Prenons un exemple, tu as l'objet métier "De" avec ses caractéristiques métier (nombre de faces,...bref là tu vois). On peut alors créer un objet "DeVue" qui va posséder des caractéristiques purement graphiques comme la couleur, la position sur un plateau,...et une référence vers le "De" qu'il doit afficher.

Regardes ce qui se dit sur le modèle MVC (Modèle-Vue-Contrôleur) tu trouveras ton bonheur je pense