Qui connait qui ?

Bonjour,

Dans mes différents développement, je me suis plusieurs fois retrouvé dans la situation où j'ai un univers et des éléments dans cet univers. L'univers connait les positions des éléments qui le compose, et pour chaque éléments, je me retrouve à lui donner sa position dans l'univers, ce que je trouve super moche, puisqu'il faut qu'à chaque déplacement d'un élément, je mettes à jour sa position stockée dans l'univers, ainsi que sa position sur lui-même.

Sauriez-vous comment rendre ça un peu plus élégant :) ?

Tu peux être plus spécifique dans ta question ?
Sinon je pourrais te répondre que le tableau de Dimitri Mendeliev donne à chaque élément chimique une position tout à fait satisfaisante.

Si l'univers ne fait que contenir les éléments, un simple tableau d'éléments suffit. Ton univers pourra connaitre la position de chaque élément via quelque chose du genre elements[i]->position

Ma réponse étant limite triviale, je me dis que ce n'était pas celle là que tu attendais. Qu'est-ce qui manque dans ma réponse et dont tu aurais besoin ?

Hum... d'après ce que j'ai compris du PO, la question serait:

vaut il mieux:

Code:

---

1 2 3 4 5 6

element { position p; data d; } univers = new element[...];

---

ou

Code:

---

1 2 3 4 5

element { data d; } univers = new map<position,element>;

---

En fait, si je prends l'exemple d'un plateau de jeu, je donne au plateau un tableau a 2 dimensions où je mets des pions. Donc, dans ce cas là, mon plateau connais la position des pions (utile pour savoir qui est le voisins). Maintenant si je mets un évènement sur mes pions et que la position doit être connue(genre déplacement), c'est plus rapide si le pion connait sa position, plutôt qu'il l'a demande au plateau qui doit cherché où il se trouve pour le déplacer.

Et même si mon évènement est au niveau du plateau, il va devoir cherché quel pion a déclenché cet évènement.

Alors oui effectivement, une hash map pourrait être utilisée pour réduire le temps de recherche de l'élément dans le plateau.

edit: fôtes.

Je ne suis pas sur d'avoir bien saisi la question. Je crois que c'est une question de point de vue.

Soit c'est ton plateau qui "agit", soit c'est les pions.
Je m'explique. Si c'est le plateau qui agit, ton plateau est un gros tableau à double entrée, et à la position x, y, tu as un objet "pion". Cet objet ne connait pas sa position, c'est du ressort du plateau. L'objet sait juste ce qui ne dépend que de lui comme par exemple sa couleur.
Si tu veux avancer un pion, c'est par le plateau que tu passes. Par exemple,
plateau->deplace_pion(pos_x_depart, pos_y_depart, pos_x_arrive, pos_y_arrive).
(Tu peux remplacer la position d'arrivée par un déplacement, genre +3 en X et -2 en Y, c'est éventuellement plus agréable à l'utilisation).
Tu dis à tel pion d'aller à telle case, et le plateau fait au passage les vérifications d'usage, genre, est-ce qu'il y a déjà un pion à l'endroit visé, est-ce que le mouvement est régulier, est-ce qu'il y a bien un pion au coordonnée indiquée... ?

L'autre solution, c'est le "pion" qui agit. Et là, on se retrouve un peu dans l'idée d'acteur/agent. Le pion va emettre un message "je veux aller a tel endroit" et les autres vont lui répondre oui ou non. S'il n'y a que des "oui" en réponse, le pion se mets à jour.

Bon, la première implémentation est clairement la plus facile ^^

Dans tous les cas, avoir la position de la même chose stockée à deux endroits, c'est mal car source d'incoherence. Le seul cas ou c'est tolérable, c'est si tu as de gros problèmes de perf et que la duplication te fait gagner beaucoup de temps, mais à mon sens, c'est à ne jamais faire de façon préventive.

Moi je ferai un truc comme ca (mais en fait je crois que c'est justement ce que tu trouve peu élégant) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Univers { vector<Pion> pions Pion* plateau[WIDTH][HEIGHT];   // ... };   class Pion { int x,y;   // ... }

---

Le vecteur permet d'optimiser sur le parcours des pions (pour l'update, le rendu,...)

Le tableau de pointeur sur les pions permet d'optimiser sur la vision du jeu (recherche de voisin, de case libre, situation de jeu...)

Apres pour garder la cohérence entre les positions des pions et leur position dans le plateau (et également lire le plateau), je vois plusieurs facons :

• chaque pion connait son univers et consulte/met a jour le plateau quand il faut
• l'univers est passée par référence dans les méthodes de Pion sucueptible de consulter/modifier le plateau
• Un pion peut accéder a l'univers de manière statique (singleton,classe statique,1 seule instance active...)
• l'univers tient son plateau a jour lui même. Il est le seul a pouvoir y accéder

Ca c'est dans le cas de grosse donnée ou les pions triés de 2 manières différentes permettent de grosse optimisations. Si ce n'est pas le cas, il faut choisir soit le plateau, soit la position dans Pion et certaines méthodes seront mal optimisée mais ce sera négligeable et plus facile a gérer.

@ Frifon
Oui, c'est effectivement ce que je souhaite éviter. :)

@Rakken
Je vais plus me diriger vers la première solution plus facile :roll:. Le plateau fera tout; il décide quel pion doit jouer, et jouera le pion.

Bonjour,

Je reviens un peu sur cette discussion et je vais prendre cette fois un exemple plus parlant.

Dans le cas d'un serveur de chat multi salon (le client n'est pas connecté directement au salon mais au serveur de gestion des salons parce qu'il peut changer souvent de salon), l'objet salon a tout interet à connaître les clients présents dans chaque salon dans le cas ou un client se connecte a ce salon et qu'il souhaite récupérer la liste des autre clients connectés dans ce salon. Et il est plus facile au client de connaître le salon où il se trouve quand il veut parler.

Donc quand un client change de salon, je dois mettre à jour la liste des clients du salon et le client pour son salon courant.

Citation:

---

Envoyé par Vitis_Alba

Dans le cas d'un serveur de chat multi salon (le client n'est pas connecté directement au salon mais au serveur de gestion des salons parce qu'il peut changer souvent de salon), l'objet salon a tout interet à connaître les clients présents dans chaque salon dans le cas ou un client se connecte a ce salon et qu'il souhaite récupérer la liste des autre clients connectés dans ce salon. Et il est plus facile au client de connaître le salon où il se trouve quand il veut parler.

---

Dans ce cas particulier, je créerai une entité séparée "Connexion" qui se chargerait de faire le lien entre un utilisateur et un salon. Pour gerer les personnes présentes dans les salons, il suffit de parcourir la liste de toutes les "Connexions".

@pseudocode

si le joueur change de salon, on se retrouve dans la situation où le gestionnaire de salon cherche dans tous les salons où se trouve le joueurs pour le déplacer.
ça ne change pas vraiment le problème.

Citation:

---

Envoyé par Vitis_Alba

si le joueur change de salon, on se retrouve dans la situation où le gestionnaire de salon cherche dans tous les salons où se trouve le joueurs pour le déplacer.
ça ne change pas vraiment le problème.

---

ca change un peu le problème car toutes les informations sont dans la meme structure. Il faut ensuite organiser cette structure pour optimiser les recherches (arbre, index, ...)

En fait, c'est comme en base de donnée.
- Un utilisateur peut être dans plusieurs salons.
- Un salon peut avoir plusieurs utilisateurs.
Ca fait une relation n/n, donc pour gérer ca proprement, on crée une table intermédiare entre les deux, genre "connexion_utilisateur_salon" pour n'avoir plus que des relations 1-n.
Pour savoir quels sont les utilisateurs dans un salon préci, une requête sur utilisateur (pour les infos) joint avec connexion_utilisateur_salon où on renseigne l'id_utilisateur donne toutes les infos directement.
Et pour avoir tous les salons d'un utilisateur donné, on fait pareil, mais on renseigne l'id_salon et on joint avec la table des salons à la place de la table des utilisateurs.

@Rakken

si j'ai bien compris ce que tu proposes, c'est d'utiliser une map qui fonctionne dans les 2 sens.
Comme ça, de visu, ça me semble fonctionner 8-). Je vais me pencher la dessus.

Merci.

Je n'ai fait que reformuler un peu differement ce que propose pseudocode. Si une information est très importante pour deux (ou plus) objet, alors on ne peut pas vraiment l'attaché a l'un de ces objets, il en faut un troisième accéssible facilement par tous les objets qui ont besoin de l'info.

Citation:

---

Envoyé par Rakken

Je n'ai fait que reformuler un peu differement ce que propose pseudocode. Si une information est très importante pour deux (ou plus) objet, alors on ne peut pas vraiment l'attaché a l'un de ces objets, il en faut un troisième accéssible facilement par tous les objets qui ont besoin de l'info.

---

Effectivement c'est plus clair dit comme cela. :king: