Organisation du code pour rester "objet"

**Nasky** · 03/03/2007, 22h59

Bonjour

Je suis sur un projet et j'aurais aimé avoir votre avis sur l'organisation du code afin que celui-ci respecte bien la philosophie de l'orienté objet (car si seul le résultat est important, je peux bidouiller et ça marche toujours).

Le programme Java est un jeu, c'est un client qui se connecte à un serveur et qui lui envoie des données et il reçoit les réponses du serveur. Le client dispose d'une interface graphique. Voilà les classes de mon programme :

Ihm -> la classe représentant l'interface graphique (Swing)
Partie -> la classe qui représente la partie
Communication -> c'est la classe qui s'occupe de l'envoi et réception avec le serveur
Joueur -> c'est le joueur avec ses stats

La classe Partie contient un objet Communication et un objet Joueur. Et la classe Ihm crée un objet Partie. Jusqu'ici, ça va...

Lorsque le Joueur veut envoyer un message au serveur, j'ai pensé qu'il devait l'envoyer à la Partie qui appelle la Communication qui envoie la requête. Et la réponse serait envoyée à Communication qui l'envoie à Partie qui la donne à Joueur.

Ainsi, j'ai pensé que la classe Communication devait avoir une référence sur l'objet Partie.
Donc j'ai le pseudo-code suivant :

Code :

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

1
2
3
4
5
6
7
8
9
class Communication {
Partie p ; // reference sur la partie en cours
 
// methode qui attend la réception de données
void listen()
{
  // recoit un message msg
  p.joueur.setMsg(msg);
}

Est-ce qu'avec la dernière ligne, c'est bien le modèle que j'ai décrit au-dessus que j'ai à savoir Comunication qui envoie à Partie qui envoie à Joueur ?

Pour l'instant, j'utilise cette méthode mais j'ai vu l'excellent cours sur comment créer ses propres listeners, c'est peut-être plus propre.
Car ensuite, je vais devoir afficher des diagrammes sur mon interface graphique à chaque fois que le serveur envoie de nouvelles informations à la Partie...

Qu'en pensez-vous ?

Nas'

**gifffftane** · 04/03/2007, 08h51

Je ne sais pas s'il y a une philosophie de l'orienté objet ; ce qui est sûr, est qu'il y a des philosophes.

Et le bidouillage n'est pas une si mauvaise école que cela, pour peu que l'on se rende compte que la réalité est un esprit aux leçons souvent exigeantes...

Bref, de mon coté de petit philosophe d'une supposée philosophie, je pense que l'orienté objet commence par un texte écrit en bon français, banissant toute forme de jargon informatique.

Donc, quand tu dis Le programme Java est un jeu, c'est un client qui se connecte à un serveur et qui lui envoie des données et il reçoit les réponses du serveur. Le client dispose d'une interface graphique., cela démarre mal. Tu pourrais dire : C'est un jeu à plusieurs joueurs, chacun disposant d'un plateau de jeu. Par exemple. Et déjà on commence à voir qui est susceptible d'écouter quoi.

Après il y a la mise en oeuvre, où interviennent clients, serveurs, interfaces graphiques, et tout le saint frusquin. Dans ce monde aussi il y a des objets. Mais ils doivent rester le plus longtemps possible en référence avec des choses de la réalité. Le serveur peut être un maître de jeu, le client un joueur, la communication client / serveur un tour de jeu, etc.

Des fois, certes, il est plus facile de parler informatique directement, il ne faut pas pousser la philosophie trop loin, cela doit rester une aide, point.

Pour ce qui concerne les listeners, je trouve que c'est un modèle un peu prise de tête lorsqu'on est assuré qu'il n'y a qu'un seul objet qui écoute. Il me semble qu'ici, c'est le cas.

Dans la communication client / serveur, coté client, on est souvent obligé de faire le traitement applicatif général (donc, ici, le jeu, et il n'y a qu'un jeu), doublé d'une sorte d'interface administrateur de la communication (communication coupée, en panne, login, etc). Moi pour ça je fais deux écoutes très spécialisées, et je trouve que les choses fonctionnent mieux comme ça.

Amuses-toi bien avec tes... jeux