Discussion :

[Mehdi Feki]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 redendance !!!

Merci d'avance

[zehle]

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!

[Mehdi Feki]

je n'ai pas compris ta reponse
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

[zehle]

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...

[xavlours]

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 :

S�lectionner tout - Visualiser dans une fen�tre � part

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 !!

[Mehdi Feki]

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 ..

[Mehdi Feki]

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 !!!

[xavlours]

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 !
[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.