Comception demineur en c++

salut tout le monde


Je suis entrain de creer un jeu de demineur.

J'ai preparé toutes mes classes Case, Matrice et Jeu.

Choisi la bibliotheque sdl pour l'implementation graphique. Le probleme est que le code graphique ne doit pas etre integré dans ces classes ( soit disant dites objets metiers ). Que faire ???

La premiere idée que j'ai eu est de creer des classes graphiques qui heritent directement de leurs classes respectives .

Code:

---

1 2 3 4 5 6 7 8

class CaseGraphique : public Case { }   classe MatriceGraphique : public Matrice { }

---

Maintenant le pobleme qui se pose est la relation entre MatriceGraphique et CaseGraphique. Aucune !!!!! :? :? :?

Je ne peut pas pointé les CaseGraphique dans MatriceGraphique parceque deja la class Matrice pointe sur les differents objets Cases :arrow: redendance !!!

Merci d'avance

tu devrait pensé autrement!!
une classe abstraite pour l'affichage dont tu derive 2 autre classes : l'une pour les cases, l'autre pour la matrice!

je n'ai pas compris ta reponse 8O 8O
peux-tu etre plus clair !!!

pourquoi abstraites ??
En plus je ne dois pas changer le code des classes matrice et case pour qu'ellent herite de ta classe affichage

merci comme meme

y aura pa d'heritage!
par exemple un exemple :
pour afficher une case:
tu a dans ta classe GraphicCase une méthode Affiche(Case UneCase)
pour afficher ta matrice, tu aura certainement besoin de la classe GrapicCase puisque ta matrice est composé de Case...

A priori lorsqu'on sépare les classes graphiques des classes "applicatives", on est souvent obligé de mettre de la "redondance" (moi, des references dans tous les sens, ca ne me gene pas tant que les informations ne sont pas dupliquees).
De plus, il faut forcément des liens entre ta matrice graphique et les cases (ses sous composants). Si tu ne les définis pas toi, le GUI en aura de toute facon.
La seule redondance que tu puisse éviter (à mon humble avis) c'est de mettre un pointeur dans les Cases Graphiques vers les "cases". Tu peux l'éviter en mettant un accesseur dans ta classe Matrice qui sera appelé par ta classe MatriceGraphique pour lire les attributs des objets Cases. Tu auras un truc du genre :

Code:

---

1 2 3 4 5 6

void MatriceGraphique::dessiner() { for(//parcours des cases) CaseGraphique cg = CaseGraphique(case); // tu recuperes les parametres utiles dans Case cg.dessiner(//parametres utiles provenant de Matrice ou MatriceGraphique); }

---

[edit] faudra que j'evite de faire autre chose quand je poste un message, j'arrive souvent apres la bataille !!

:D la bataille n'est pas encore finie

merci pour ta reponse

Je suis tout a fait daccord avec toi !! Je suis pres de faire de la redondance sur ce point je n'ai aucun probleme

Le probleme de redondance que j'ai presenté dans le 1er poste n'existe que dans le cas si j'utilise l'heritage . Je m'explique encore

La class matrice contient un tableau 2 dimensions de Cases *

Si je cree Une class MatriceGraphique qui herite de Matrice les (n*m) objets cases encapsulé dans la Class Matrice vont etre instanciés lors de l'appel du constructeur de MatriceGraphique . mais moi je veux manipuler des CasesGraphiques vous voyez un peu la confusion !!!

Apparament l'heritage n'est pas une tres bonne solution pour ce cas !!! C'est ce que je constate .. :? :? :?

Donc puisque je n'ai pas encore recu de reponse concraite j'ai obté pour cette solution

Une classe jeu qui gere tous ce qui est evenement !!
une classe affichage qui a une vue sur les classes Case et Matrice et qui tout simplement affiche !!

Ce n'est pas trop beau parceque la classe Affichage a un access aux etats de matrice et case mais bon !!!

Ok, alors si tu fais de l'héritage, oui il y a redondance : ton objet Matrice et ton objet MatriceGraphique auront des attributs dupliqués .
Je te conseille fortement de faire de la délégation, justement en placant des accesseurs dans Matrice pour toutes les infos dont aura besoin ton objet MatriceGraphique.
Ton objet MatriceGraphique aura un pointeur sur ton objet Matrice, et appellera les accesseurs (getters) a chaque fois qu'il en aura besoin.
Si tu fais de l'héritage, ta classe MatriceGraphique encapsule les données graphiques et aussi les données "de metier". Tu ne réponds donc pas au choix que tu as fait au début, qui me semble très bon.
Au niveau de l'héritage, tes classes MatriceGraphique et CaseGraphique hériteront forcément d'une classe ComposantGraphique du GUI. En venant de Java, je suis pas trop habitué à l'héritage multiple et je l'évite autant que possible (mais je ne veux pas lancer un troll...). Les liens entre objets graphiques et objets metiers devraient etre des liens de délégation a mon humble avis.
Voila, j'espère t'avoir convaincu ! :wink:
[edit] Le choix que tu as fait est bon aussi, tu ne peux pas afficher des cases dont tu ne connais pas l'état. Simplement place des getters, et pas des setters. Comme ca la classe Affichage pourra lire mais pas modifier les états.