un tableau partagé par 2 classes

Version imprimable

Bonjour

j'ai 2 classes A et B
je voudrais modifier le tableau des 2 classes
"genre mon tableau en variable globale"

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
int monTableau[10];
 
classe A
{
     void ModifTableauA()
     {
          monTableau[5] = 4;
     }
}
 
classe B
{
     void ModifTableauB()
     {
          monTableau[8] = 1;
     }
}

merci

Bonjour,

Ce que vous avez fait fonctionne. Mais bon, les variables globales, ce n'est pas vraiment bien (à part rare cas, voir FAQ ou débat précédents).

Pour revenir au problème, cela est possible, si les classes acceptent un pointeur sur le tableau (ou le pointeur du tableau, à vrai dire).
Le code sera du genre:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 #include <cassert> class A { int* m_pTab; A(int* pTab) m_pTab:pTab { assert(m_pTab); } void foo() { m_pTab[2] = 42; } } class B { int* m_pTab; B(int* pTab) m_pTab:pTab { assert(m_pTab); } void foo() { m_pTab[3] = 42; } } int main() { int* pTab = new int[10]; A a(pTab); B b(pTab); for ( unsigned int i = 0 ; i < 10 ; i++ ) { std::cout << pTab[i] << std::endl; } delete pTab; return 0; }
Mais, il y a certain points que je n'aime pas vraiment.
D'abord, le tableau est partagé dans deux classes différentes et cela me chagrine (qui gère réellement le tableau, qui a des droits d'accès / d'écritures). Que se passe t'il si les deux classes modifie la même case.
Et puis, quid des cas en multithread ...
De plus, dans mon code, cela ne marche que pour un tableau ayant une taille de 4 minimum. Pour nous protéger de cela, j'utiliserai plutôt un std::vector, qui connait le nombre d'éléments contenus.

Enfin voilà, je pense avoir au moins répondu à la "question" de base.

04/11/2011, 09h25
ccinfonews

pas facile la POO parfois
merci de la réponse
04/11/2011, 12h56
Steph_ng8

Citation:

Envoyé par LittleWhite

D'abord, le tableau est partagé dans deux classes différentes et cela me chagrine (qui gère réellement le tableau, qui a des droits d'accès / d'écritures).

Idem.
De plus, qui est responsable de sa création ? de sa destruction ?
Ce serait problématique d'essayer d'accéder à un de ses élément alors qu'il n'existe pas encore ou qu'il n'existe plus...

en fait je pensais qu'on pouvait s'en sortir en utilisant les références ou pointeurs
en réfléchissant j'ai résolu le pb autrement mais je suis peut être sorti de la phylosophie de la POO
si un puriste pouvait me répondre à cette exemple simplifié qui fonctionne !

***** création d'un jeu de poker *****
- il y a une classe Donne, une classe Joueur et une classe Dealer
- autant d'instance Joueur que de joueur
- dans cette classe il y a un tableau public contenant les cartes du joueur
- la classe Donne gère la partie
- elle passe à la Classe Dealer, par une méthode, le tableau des cartes des joueurs vides par pointeur
- donc le tableau de la Classe Joueur contient les cartes distribuer
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 class Joueur { public: int tabCarteJoueur[2]; // je sais un attribut public c'est pas terrible void ContenuDetabCarteJoueur() { // j'ai vérifier : après l'appel Donneur.Distribuer... // ici tabCarteJoueur[0] contient bien 12; // ici tabCarteJoueur[1] contient bien 25; } } class Dealer { public: void Distribuer(int *tabCarteJoueur) { tabCarteJoueur[0] = 12; tabCarteJoueur[1] = 25; } } class Donne { Joueur Joueur1; Dealer Donneur; // exemple pour un joueur pour ne pas compliquer Donneur.Distribuer(Joueur1.tabCarteJoueur); }

04/11/2011, 14h24
LittleWhite

Personnellement, je n'aime toujours pas.

Dans une approche beaucoup plus objet, il faudrait que le jeu de carte soit un objet (JeuDeCarte) et les cartes elle même soit des objets (Carte).
Après, le jeu de carte, disposerai d'une fonction pioche, qui enlèverai une carte pour la donner (copie ou référence) à un joueur.
Et c'est le JeuDeCarte qui gère les cartes (création / destruction).

Enfin bref, mon approche n'a aucun rapport avec votre code (et elle est possiblement perfectible).
Là, ce qui me gène, c'est que vous donner accès à un membre d'une classe, et cela vers l'extérieur de celle-ci (un pointeur vers un membre). Ca casse le principe de l'encapsulation ...
04/11/2011, 14h48
ccinfonews

je sais bien que je ne respecte pas l'idée de base de la POO
par contre je pense que mon analyse tient la route

(une partie de l'analyse)
- la classe Donne : elle conduit la partie de A à Z - elle connait le principe du déroulement du jeu
- la classe Joueur : elle a des cartes - elle décide de qu'elle va faire en fonction de son jeu - elle a une somme de jetons
- la classe Dealer : elle se charge de mélanger les 52 cartes - donner 2 cartes à chaque joueur - montrer le flop, turn et river

je suis parti de cet exemple assez concret (et à la mode - poker) pour étudier la POO

Tu devrais suivre les conseils donnés par LittleWhite.
Surtout si tu comptes réellement développez un jeu de poker.
J'ai moi-même développé il y a quelques années une petite application de texas hold'em en réseau en Java.
Et je me souviens avoir eu de nombreuses classes pour représenter chaque chose comme :
-Card
-DeckCard
-Game
-Hand
-Table
-Seat
-Combination
-etc... et de nombreuses autres

Et pour éviter que le dealer accède au tableau de 2 cartes, tu peux aussi changer la façon de voir les choses. Par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 classe Joueur { public: void recevoirCarte(int i, int a) { tabCarteJoueur[i]=a; } private: int tabCarteJoueur[2]; } class Dealer { public: /* Renvoi un int compris entre 0 et le nombre de cardes encore disponibles et tu t'arranges pour obtenir la prochaine carte disponible à partir de cet entier dans ton tableau de cartes*/ int deal(); /* fait le tour des joueurs présent dans la main*/ void distribuer(){ ... /* quelquepart tu appelles recevoirCarte(0,deal()); puis recevoirCarte(1,deal()); */ ... } }
Ca n'est qu'une fois façon de voir les choses mais réfléchis mieux à ta structure. Au poker, tu auras une table avec des joueurs qui peuvent entrer ou sortir à chaque main (d'ou l'importance d'avoir une classe Hand te permettant d'avoir les joueurs présents et non sit-out à un moment donné)..
Il y a de nombreuses choses à penser.

04/11/2011, 16h01
ccinfonews

post intérressant Xtrem_Voyageur
tu m'as ouvert les idées et fait monter d'un niveau :ccool:

par contre comme on crée une instance par joueur comment fait on pour appeller la méthode recevoirCarte() de chaque joueur
04/11/2011, 16h50
Bousk
Citation:

Envoyé par ccinfonews

par contre comme on crée une instance par joueur comment fait on pour appeller la méthode recevoirCarte() de chaque joueur

Je ne comprends pas le souci ?
Code:

1 2 3 4 instanceJoueur1.recevoirCarte(...); instanceJoueur2.recevoirCarte(...); // etc
il faut juste créer ces joueurs et pouvoir les retrouver
04/11/2011, 22h24
ccinfonews

oui ca pas de pb
mais comme les instances sont créées dans la classe Donne comment sont-elles visibles de la classe Dealer

Tu ne possèdes pas les bases minimum pour faire ce que tu veux faire. Je ne critique pas, vouloir programmer ce genre de choses peut te faire avancer mais il faut tout de même avoir lu et compris les bases de la base et là visiblement tu ne les possèdes pas.
Pour ton petit problème.

Quand tu crées un objet de type A. Tu peux lui appliquer toutes les méthodes de la classe A que tu as défini publiques.

Bien que ta classe Donne ne soit pas du tout une bonne idée en terme de conception (je t'expliquerai un petit peu pourquoi par la suite) et que je m'empresserai de donner une structure correcte avant de programmer. Saches que tu as créé une instance de joueur dans ta classe Donne. Tu peux donc appeler la fonction membre de ta classe Joueur sur cette instance vu que cette fonction membre est publique. Tu as juste à faire
Code:

1 2 joueur1.recevoirCarte(0,deal());
Attention tout de même ce code ne marche que si tu le fais dans la fonction distribuer de la classe que j'ai donné avant.

Concernant la conception, il faut se poser des questions simples pour la POO, du style, qu'est ce qui contient quoi, qu'est ce qui fait partie de.
Tu as mis un Joueur et un Dealer dans la classe Donne, est-ce une bonne idée?
N-y a-il pas une structure plus judicieuse.
Un exemple simple :

Pour moi une partie de poker de déroule sur une table. Sur cette table se dérouleront des mains qui doivent être rattachées à une partie (plusieurs parties peuvent en effet avoir lieues simultanément sur plusieurs tables)

Tu pourrais donc commencer par avoir une classe Game
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class Game { private: CardsPack cp; // Un paquet de cartes constitués de Cartes (à définir en tant que classe) int nPlayersIn; // nombre de joueurs dans la partie int nHands; // nombre de mains faites depuis le début de la partie PokerTable pt; // un objet représentant la table de poker. Il faudra bien placer les joueurs autour de la table et il y a plusieurs types de tables possibles (6joueurs, 10 joueurs, 2 pour les heads-up) double betMin; // pour caractériser la limite de ta partie, ça ressemble la Big Blind si tu veux public: Game(PokerTable& table) // Ton constructeur, à qui il faudra au moins passer un objet PokerTable pour l'associer à l'objet Partie. };
une classe Player
Code:

1 2 3 4 5 6 7 8 9 10 11 12 class Player { private: std::string name; // son nom double money; // son stack bool inGame; // Est-il actif dans une partie? short seat; // son numéro de siège à la table (-1 lorsque le joueur n'est pas assis à une table) short tabDeal[2]; // Pour contenir ses 2 cartes public: Player(std::string n, double m, bool b=false, short s=-1); };
une classe Hand
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 class Hand { private: Game game; // A quelle partie appartient cette main? Player sb; // Joueur small blind durant cette main Player bb; // Joueur big blind durant cette main int nPlayerIn; // nombre de players dans la main int nPlayerAllIn; // nombre de players all in durant la main (peut évoluer durant les différentes phase du jeu : flop, turn et river) int pot; public: Hand(Game& g); // Rattacher la main à une partie };
Voilà c'est juste pour te donner une idée.

07/11/2011, 09h06
ccinfonews

pas de pb avec cette organisation

on sait qu'en développement il y a souvent plusieurs facons de programmer pour arriver au même résultat...

est-ce qu'en POO, pour un projet donné, il y a une seule facon d'organiser les classes ou plusieurs selon la vision du concepteur (niveau expert bien sur) ?
07/11/2011, 12h43
koala01
Salut,

Citation:

Envoyé par ccinfonews

pas de pb avec cette organisation

on sait qu'en développement il y a souvent plusieurs facons de programmer pour arriver au même résultat...

est-ce qu'en POO, pour un projet donné, il y a une seule facon d'organiser les classes ou plusieurs selon la vision du concepteur (niveau expert bien sur) ?

Il y a toujours autant de manière de concevoir les choses qu'il peut y avoir de personnes qui tentent de les concevoir, mais il existe quelques règles de conception "simples" à respecter qui font que, au final, si plusieurs personnes s'attaquent à un besoin identique basé sur une situation de base identique, il est plus que vraisemblable qu'ils obtiendront malgré tout un résultat fort similaire, à défaut d'être tout à fait identique.

On peut citer, pour la conception générale (pas uniquement Orientée Objet) :
- KISS : Keep It Simple, Stupid (en français : Gardez cette chose simple, stupide) les fonctions et les objets que tu crées doivent rester simples, à la limite de la stupidité. Cela te permettra de comprendre facilement ce qui est fait et pourquoi
- ORP : One Responsability Principle (en français : principe de la responsabilité unique) Une classe ou une fonction ne doit jamais faire qu'une seule chose. Si la fonction commence à faire plus d'une seule chose, si la classe commence à avoir plus d'une responsabilité, c'est sans doute qu'elle en fait trop
Du coté "Conception orienté objets", on trouve des principes comme:
- La loi demeter : si une classe A utilise la classe B en interne, l'utilisateur de la classe A ne devrait pas avoir à connaitre l'existence de la classe B pour manipuler la classe A (ex : on sait qu'une voiture a un réservoir à carburant, on sait que la voiture l'utilisera pour une série de choses, mais, en tant qu'utilisateur de la voiture, on n'a aucun besoin d'accéder à l'élément "réservoir à carburant" de la voiture pour y chipoter nous même)
- Le principe d'encapsulation : il faut réfléchir non plus en fonction des données dont dispose un type donné, mais plutôt en terme de services attendus: ce sont les services que l'on va demander à un type donné qui vont déterminer les données qui sont nécessaires pour lui permettre de le faire. Les données en elles-même deviennent des "détails d'implémentation" qui ne modifient en rien les services qui seront demandés de la part de l'objet
- OCP : Open Close Principle (En français : le Principe "Ouvert / Fermé) Les classes que tu crées doivent être ouvertes à l'évolution, mais fermée à la modification : une fois que tu as créé ta classe, tu dois pouvoir te rendre compte à l'usage qu'il faut lui permettre de rendre un service supplémentaire auquel tu n'avais pas pensé dans un premier temps, par contre, il ne faut pas que le fait de rajouter ce service ne vienne à modifier la manière dont les autres services sont rendus
- LSP : Liskov Substitution Principle (en français : principe de substitution de Liskov) L'héritage public ne doit être envisagé que lorsque l'on peut décemment estimer de manière sémantique que l'objet de type dérivé est bel et bien un objet du type de base
Pour mettre tous ces principes en musique, il faut partir d'une bonne analyse fonctionnelle.

Cela signifie qu'il faut commencer par analyser correctement les besoins auxquels tu vas être confronté.

Dans un premier jet, on peut estimer que chaque nom commun utilisé dans ton analyse devra se retrouver traduit sous la forme d'une classe particulière et que chaque verbe utilisé dans ton analyse des besoins devra se retrouver traduit sous la forme d'une fonction (voire d'une fonction membre).

Ainsi, tu as décidé de créer une application de poker.

Mais le pocker, c'est... un jeu de cartes: il faudra donc disposer d'une classe Carte capable de représenter à chaque fois une des 52 cartes que l'on trouve habituellement dans un jeu de carte (as, deux, trois, quatre... valet, dame, roi en pique, coeur, carreau ou trèfle) et... un conteneur de cartes qui gardera les cartes non distribuées.

A coté des cartes, il y a des joueurs, qui se trouvent autour d'une table et qui participent (ou non) à ce que l'on appelle une main, et plusieurs mains vont correspondre à une partie.

Outre les joueurs, il y aura "le distributeur" ou "la banque", enfin, "quelque chose" qui est responsable de la distribution des cartes aux joueurs et qui "mène la danse".

Il ne faut pas oublier le système qui s'occupera de gérer les mains, de les faire commencer et d'en marquer la fin

Tu dois donc retrouver ces éléments dans les classes que tu vas créer.

J'oublie très certainement quelques acteurs (par méconnaissance du poker en lui-même :D ), pour gérer les règles et autres joyeusetés du genre, mais, si tu respecte le fameux principe de la responsabilité unique, tu devrait n'avoir pas trop de mal à les retrouver ;)

Ce sont les relations qui existent entre tout ce beau monde, les services que ces différentes classes vont demander / rendre aux autres qui vont te permettre de créer un système homogène et cohérent qui sera, au final, ton application de poker!

De ce fait, si plusieurs personnes partent d'une analyse correcte identique, il y a de très fortes chances pour que l'on se retrouve avec un système globalement fort proche quelle que soit la personne qui l'aura créé.

L'analyse qui a amené Xtrem_Voyageur à créer le système qu'il a esquissé dans ses interventions précédentes me semble beaucoup plus cohérente que la tienne ;)

En fait, j'ai l'impression que tu n'es surtout pas allé assez loin dans l'analyse de tes besoins, et que tu as *peut etre* pris des raccourcis qui risquent de s'avérer dommageables sur le long terme (lorsque justement, tu te rendra compte que tu as laissé de coté des pans entiers d'analyse) :aie:
07/11/2011, 14h19
ccinfonews

tu as tout a fait raison koala
l'analyse est resté volontairement superficielle...
je ne souhaite pas développer à tous prix un jeu de poker mais juste le prendre comme exemple pour manipuler les classes

on nous présente toujours, dans les tutos, des exemples de premiers niveaux pour commencer, et c'est très bien d'ailleurs, mais rarement un thème simple mais assez complexe dans son organisation

je reviens sur un truc qui n'a pas été expliqué

d'après Xtrem_Voyageur
il est clair qu'on a une classe Joueur (Player)
dans la classe Game on va créer N instance de Player, autant qu'il y de joueurs à la table

(ne compliquons pas ! mais je commence à comprendre que les joueurs appartiennent plûtot au tournoi :D voire qu'ils pourraient exister en tant qu'être humain et participer à un tournoi etc... ne nous élevons pas trop)

il va y avoir une classe Card et une classe Dealer
comment va s'organiser le passage des cartes entre le Dealer et le Player ?
07/11/2011, 17h46
koala01
Citation:

Envoyé par ccinfonews

tu as tout a fait raison koala
l'analyse est resté volontairement superficielle...
je ne souhaite pas développer à tous prix un jeu de poker mais juste le prendre comme exemple pour manipuler les classes

Cela peut se comprendre, mais, meme si l'idée est de n'implémenter qu'une partie du programme, il faut malgré tout essayer d'avoir une analyse qui tient la route ;)

Citation:

on nous présente toujours, dans les tutos, des exemples de premiers niveaux pour commencer, et c'est très bien d'ailleurs, mais rarement un thème simple mais assez complexe dans son organisation

C'est effectivement le problème de la plupart des tutos : il faut trouver quelque chose qui soit facile à comprendre, et donc, généralement simplissime dans la conception.

Les projets réels ont en effet une tendance naturelle à enfler de manière assez incroyable :D

Citation:

je reviens sur un truc qui n'a pas été expliqué

d'après Xtrem_Voyageur
il est clair qu'on a une classe Joueur (Player)
dans la classe Game on va créer N instance de Player, autant qu'il y de joueurs à la table

(ne compliquons pas ! mais je commence à comprendre que les joueurs appartiennent plûtot au tournoi :D voire qu'ils pourraient exister en tant qu'être humain et participer à un tournoi etc... ne nous élevons pas trop)

il va y avoir une classe Card et une classe Dealer
comment va s'organiser le passage des cartes entre le Dealer et le Player ?

En fait, on se rend compte que la classe Card sera vraisemblablement utilisée un peu partout, parce que c'est la base "atomique" de tout jeu de carte.

le Dealer va donc disposer de l'ensemble des cartes qu'il est susceptible de donner aux joueurs et proposer (entre autre) un service "donne moi une carte"

Comme le Dealer et les joueurs font partie d'une table, il est doit possible, lorsque l'on est au niveau de la table, de s'adresser à un joueur donné en lui disant "joue en t'adressant à tel Dealer".

Cela prendra simplement la forme d'une fonction play(Dealer & d); qui sera membre de la classe Gamer

L'objet de type Gamer en cours d'utilisation(donc le joueur dont c'est le tour :D ) va profiter du Dealer transmis en paramètre pour lui demander de lui passer une carte :
Code:

1 2 3 4 5 void Gamer::play(Dealer & d) { Card firstCard = d.giveMeACard(); Card secondCard = d.giveMeACard(); }
la fonction giveMeACard va renvoyer un objet de type Card et s'assurer que la carte renvoyée ne pourra, en tout état de cause, plus être utilisée avant la fin de la main en cours ;)

Au cours de la main, on ne s'adressera plus au Dealer que pour demander les cartes supplémentaires (rivières et autres), et, si on a besoin de savoir quelles cartes sont tenues par un joueur donné, on lui posera directement la question ;)

Une fois que la main est finie, les joueur et "la banque" rendent l'ensemble des cartes qui ont été distribuée grâce à une autre fonction membre du Dealer "retour de carte"
Code:

1 2 3 4 5 6 7 8 9 10 void Gamer::endOfHand(Dealer & d) { d.backCard(firstCard); d.backCard(secondCard); } void Bank::endOfHand(Dealder & d) { d.backCard(river); /* ... */ }
ce qui aura comme résultat de remettre le Dealer dans un état correct et cohérent pour le début de la main suivante (cohérent dans le sens où il disposera à nouveau de l'ensemble des cartes ;) )