Discussion :

[pierrot547000]

Bonjour,

Je suis en train de coder un peu jeu d'échec en python3 pour le fun. J'en suis à la phase de concept, donc il est possible que la réponse attendue ne soit pas du code 'pur', mais plutôt une méthode.

J'ai découpé mon code :
- J'ai un fichier qui contient une classe "block". Chaque "block" est en fait une case du plateau qui contient des caractéristiques (sa position, sa couleur, case occupée ou libre, etc)
- J'ai un autre fichier qui contient une classe "piece". Chaque "piece" est en fait une pièce du jeu qui contient d'autres caractéristiques (type de pièce, appartient à quelle camp, peut ou ne pas pas se déplacer, a déjà bougé, etc)

J'ai commencé à instancier mes 64 "block" (pour mes 64 cases), et dans ma classe block, j'ai une propriété 'piece' qui contient une instance de la pièce qui occupe cette case (si une pièce occupe effectivement la case). Du coup, depuis ma case, je peux accéder aux propriétés de la pièce qui l'occupe, super, dans ce sens ça marche, pas de problème Voici un extrait du code (que j'ai laaaaaaargement simplifié pour bien expliquer mon problème) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
class block():
	piece = None
	color = ''
	position = 0
 
 
 
	def __init__(self, piece, color, position):
		self.piece = piece #je donne en paramètre une instance de ma pièce
		self.color = color
		self.position = position

Mais imaginons que j'ai besoin de le faire dans l'autre sens. Càd que depuis ma pièce, je souhaite accéder aux caractéristiques de la case qu'elle occupe, alors là, c'est un autre délire, je ne sais pas comment faire. Avez-vous une idée svp ?

[wiztricks]

Salut,

Mais imaginons que j'ai besoin de le faire dans l'autre sens. Càd que depuis ma pièce, je souhaite accéder aux caractéristiques de la case qu'elle occupe, alors là, c'est un autre délire, je ne sais pas comment faire. Avez-vous une idée svp ?

Pourquoi ne pas créé côté Piece un attribut "block" qui sera assigné avec la case?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
	def __init__(self, piece, color, position):
		self.piece = piece #je donne en paramètre une instance de ma pièce
                piece.block = self
		self.color = color
                ...

Ceci dit, j'éviterais ce genre de références "circulaires" autant que possible: lorsqu'une piece "bouge" vous aurez à gérer la mise à jour d'un attribut côté "case" et de celui côté "piece".

Dans ce cas particulier, vous avez un ensemble de cases dont chaque élément sera désigné par ses coordonnées (i, j) et un ensemble de pièces, chacune ayant pour attribut une position (i, j) - qui peut changer au cours du jeu.
Si "cases" et "pieces" sont des dictionnaires, pour chaque (i, j), pieces.get((i, j)) retournera None ou la pièce en (i, j). Sans "pieces", cases[i, j].piece fonctionne bien aussi, avec éventuellement cases[i, j].piece.position retournant (i, j).

- W

[pierrot547000]

Okay merci du tuyau, je confirme que je veux le faire dans les deux sens. Càd que :
- depuis une case, je veux pouvoir accéder à la pièce qui occupe cette case
- depuis une pièce, je veux pouvoir accéder à la case où la pièce se trouve.

[Bktero]

Ce n'est pas parce que tu veux le faire que c'est une bonne idée

Classiquement dans la POO, quand un objet utilise un autre objet, on dit qu'il sont liés par des relations de composition et d’agrégation (voir https://www.developpez.net/forums/d1...n-composition/ ou http://www.lechatcode.com/architectu...ion-cest-quoi/). Il est rare qu'une telle relation soit dans les 2 sens. Je rejoins wiztricks sur ce point

Si tu as besoin de connaitre la pièce d'une case et la case d'une pièce, peut-être qu'il serait plus intéressant de gérer au niveau de l'échiquier.

Il faut savoir qu'il y a toujours plusieurs designs possibles pour résoudre un problème. Plusieurs bonnes solutions et certainement beaucoup encore de mauvaises. Quand tu codes et que tu arrives à des cas tordus, difficiles à implémenter, alors il faut se poser la question de ton design. Tu as le droit, et même tu devrais revoir ton design si tu trouves des problèmes lors de l'implémentation.

Sans dire que ton design est forcément mauvais, la difficulté que tu rencontres devrait t'amener à t'interroger sur ton design et décider si tu souhaites le garder ou si tu souhaites le changer.

Si tu veux maintenir ce double lien :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Case:
    def __init__(self, x, y):
        self.piece = None
        self.x = x
        self.y = y
 
class Piece:
    def __init__(self, piece):
        self.piece = piece
 
 
case = Case(1, 2)
piece = Piece(case)
case.piece = piece

[pierrot547000]

effectivement, vous avez raison tous les deux sur ce point. C'est bien une histoire de design. Merci beaucoup de m'avoir éclairé à ce sujet, ça fait plaisir ; un regard neuf c'est exactement ce dont j'avais besoin

Merci et bonne journée.