Discussion :

[Malikemal]

Donc si tu as une même régle qui s'applique à plusieurs piéces, la logique est dupliquée dans l'ensemble des pièces qui doivent respecter cette règle ?

J'y ai pensé aussi Mais ça ne s'applique que dans un seul cas : la reine qui se déplace soit comme une tour soit comme un fou. Je ne pense pas que j'aurai dû diviser cela en deux classes à cause de ça. Une duplication du code vaut-elle un code long comme une girafe et redondant à souhait ? Pour moi, dans ce cas-là la duplication est ce que j'ai choisi.

[johnlamericain]

J'y ai pensé aussi Mais ça ne s'applique que dans un seul cas : la reine qui se déplace soit comme une tour soit comme un fou. Je ne pense pas que j'aurai dû diviser cela en deux classes à cause de ça. Une duplication du code vaut-elle un code long comme une girafe et redondant à souhait ? Pour moi, dans ce cas-là la duplication est ce que j'ai choisi.

Tu as raison dans le sens ou un code long avec des switch ou if n'est pas quelque chose à favoriser, je suis loin de dire cela. Cependant du code dupliqué et plus dur à maintenir, si une erreur est trouvé, la modification est alors à apporté dans les 2 ou + morceaux de code, etc. Tu peux aussi découper ça dans plusieurs plus petites fonctions (classe d'aide aux règles) qui auront des tests unitaires (évidemment ) et du coup tes 2 pièces ne font qu'appeler la même fonction au besoin.

Par contre je ne suis pas d'accord sur le fait que tu auras qu'un seul cas de code dupliqué pour les règles, on en reparlera à la fin de l'implémentation

[Malikemal]

Ça nécessiterai un gros changement d'architecture de mon code, et je manque vraiment de temps ... Je ne peux coder que le WE (et là encore seulement un temps très limité), si on compte qu'en plus j'ai un mois de retard et que Qt Creator me sort des erreurs bizarres, je m'y retrouve difficilement !

Néanmoins je m'incline devant tes arguments

[Malikemal]

QtCreator me sort des problèmes ... bizarres. Le compilateur me dit par exemple que "vector does not a name type" alors que j'ai bien l'include Vous savez pas d'où ça peut venir ? Sachant que ça le fait pour d'autre choses (une enum aussi, et une classe) (Je n'ai pas très envie de créer un topic pour si peu ...)

EDIT : Comme si il ne prenait pas en compte les includes ...

[Amnell]

Bonsoir,

Sans plus d'informations, je dirais que cela ressemble à un problème de dépendances cycliques.

Bonne soirée,
Amnell.

[Malikemal]

Comment ça se soigne docteur ? Besoin du code ? Je pense effectivement que c'est ça.

EDIT : Après vérification, c'est bien de là que vient le problème mais je ne peux pas faire autrement ! Ma classe Echiquier prend pour certaines méthodes des "Pieces" en paramètres et inversement pour la classe Piece ... Comment je me débrouille ?

[Amnell]

Comme ceci ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#ifndef TRUC_H_
# define TRUC_H_
 
class Piece;
 
class Equiquier
{
public:
    void doSomething(Piece *, int);
};
 
class Piece
{
public:
    void doSomething(Echiquier *);
};
 
#endif

[dourouc05]

Ou #pragma once, même si ce n'est pas trop standard.

[Malikemal]

Comme ceci ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#ifndef TRUC_H_
# define TRUC_H_
 
class Piece;
 
class Equiquier
{
public:
    void doSomething(Piece *, int);
};
 
class Piece
{
public:
    void doSomething(Echiquier *);
};
 
#endif

Mettre les définitions de classes dans le même fichier ? En effet, je n'y avais pas pensé !

Je vais rester sur du standard de préférence pour l'instant

Merci,

[Amnell]

Mettre les définitions de classes dans le même fichier ? En effet, je n'y avais pas pensé !

Pas forcément dans le même fichier :
http://cpp.developpez.com/faq/cpp/?p...erence_croisee

[Malikemal]

C'est encore mieux alors !

Merci beaucoup,

[Malikemal]

Bon alors, après un rapide coup d'œil à mes erreurs de compilation je me suis rappelé pourquoi j'avais commencé à étudier le Python ... Je vais faire chauffer l'interpréteur

[0x4e84]

Bon alors, après un rapide coup d'œil à mes erreurs de compilation je me suis rappelé pourquoi j'avais commencé à étudier le Python ... Je vais faire chauffer l'interpréteur

Bienvenue au club des Pythoneurs ;-)

[Malikemal]

Bonjour à tous,

Étant donné que je recommence l'application, j'ai décidé de recommencer proprement. J'ai donc fait ce petit diagramme :


Je me demandais déjà ce que vous en pensiez, et aussi un avis sur ça :
Pour gérer les différents types de jeu (homme vs homme, ordi vs homme, réseau, etc ...) j'ai prévu d'utiliser une classe pour chaque, qui hérite toutes d'une classe "Jeu", celle que vous voyez. Mais pour pouvoir créer une instance de la bonne classe, je vais utiliser des instructions conditionnelles ... Est-ce que c'est une manière "propre" ? Ou y-a-t'il une meilleure manière de procéder ?

Code :

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

1
2
3
4
5
6
7
8
9
#Un exemple
if jeuEnReseau:
    jeu = Resau()
elif jeuHvsH:
    jeu = HvsH
elif jeuHvsOrdi:
    jeu = HvsOrdi
else:
    #Exception

Étant donné qu'il héritent tous de Jeu, je pourrai utiliser seulement les méthodes de cette classe ... Alors ?
Merci,

[LittleWhite]

Je ne vois pas pourquoi le RulesManager est aussi proche du Controlleur.

[Malikemal]

Tu veux dire d'un point de vue purement graphique ?
Sinon sûrement parce que seule la classe Controleur l'utilise !

[LittleWhite]

Pourquoi est ce le Controlleur qui vérifie les coups et non le jeu ?

[Malikemal]

Le Principe de Responsabilité Unique ! La classe Jeu s'occupe déjà de redistribuer les coups, donc elle ne peut pas s'occuper d'autre chose.

[LittleWhite]

Alors le controlleur s'occupe de créer (récupérer) les coups. (et paf !)


Disons que la responsabilité unique, c'est le fait que chaque classe possède une et une seule responsabilité (soit, elle ne s'occupe que d'une chose et elle le fait bien).
Ici, je demande juste pourquoi vous le faites comme cela. Cela ne me semble pas faux.

Par contre, votre Affichage me semble notifier deux fois, pour chaque coup ?

[Malikemal]

Alors le controlleur s'occupe de créer (récupérer) les coups. (et paf !)


Disons que la responsabilité unique, c'est le fait que chaque classe possède une et une seule responsabilité (soit, elle ne s'occupe que d'une chose et elle le fait bien).
Ici, je demande juste pourquoi vous le faites comme cela. Cela ne me semble pas faux.

J'ai pas compris là :/ Mais faut pas pousser non plus

Par contre, votre Affichage me semble notifier deux fois, pour chaque coup ?

La notification venant du controleur correspond à : - si une pièce est sélectionné à envoyer les déplacements valides
- sinon vérifie que la pièce sur laquelle on clique peut bouger, si oui on envoie les déplacements possibles. Je pense que je vais faire ça dans une autre classe mais je ne voulais pas alourdir inutilement le graphique.