Discussion :

[Dani3L]

Bonjour

Lorsque je programme, je me pose régulièrement la même question lorsque je réfléchis à l'organisation de mes classes.

Je me demande souvent par exemple comment faire communiquer mes classes entre elles ?

Par exemple dans le cadre d'un programme de simulation. Si j'ai une classe Affichage qui s'occupe de la gestion de l'affichage à l'écran (OpenGL) et une classe Simulation qui s'occupe de calculer les états de la simulation. Lorsque la classe Simulation calcule les nouveaux paramètres de la simulation, elle a besoin d'en informer la classe Affichage (certaines variables de la classe d'affichage doivent être mises à jour pour le prochain affichage). Mais dans ce cas, comment gérer la communication entre les deux classes.

On pourrait par exemple passer à la classe Simulation un pointeur sur l'instance de la classe Affichage. De cette façon, la classe simulation peut modifier elle même les valeurs de la classe affichage.

On pourrait aussi instanciée la classe Simulation à l'intérieur de la classe Affichage.

Je n'arrive donc pas à voir comment gérer la communication de manière PROPRE. Je voudrais donc savoir ce qu'il est conseillé de faire dans ce genre de situation. En effet, c'est un problème que je rencontre régulièrement.

Deuxièmement, je me pose une autre question à propos des classes que l'on instancie une seule fois dans le programme. Par exemple dans l'exemple précédent, on utilisera une seule instance de la classe Affichage. Je voudrais savoir s'il est préférable de créer une seule instance de cette classe (Affichage affichage = new Affichage() ) ou bien d'utiliser cette classe de manière statique (en déclarant toutes ces méthodes statiques) ?

Merci d'avance de m'aider un peu. Ce serait vraiment sympa.
Salutations.

[Médinoc]

Je dirais une seule instance de Affichage, typiquement suivant le pattern Singleton.

[Dani3L]

Donc, pour l'exemple de simulation que j'ai cité, on pourrait faire que les classes Affichage et Simulation soient des singletons (car elle ne seront créés qu'une seule fois dans le programme) et toutes les autres classes sont des classes normales (par exemple un classe Voiture pour une simulation de course automobile). Ne risque-t-on pas d'avoir trop de classes singleton ?

Est-ce que quelqu'un aurait une suggestion à propos de mon premier problème qui concerne la manière de communiquer entre deux classes ?

[bolhrak]

Donc, pour l'exemple de simulation que j'ai cité, on pourrait faire que les classes Affichage et Simulation soient des singletons (car elle ne seront créés qu'une seule fois dans le programme) et toutes les autres classes sont des classes normales (par exemple un classe Voiture pour une simulation de course automobile). Ne risque-t-on pas d'avoir trop de classes singleton ?

En quoi serait-ce un problème ?

De manière plus générale, la structure de ton programme permet aussi d'éviter d'avoir plein de singletons. Par exemple si seule ta classe Affichage (qui est déjà un Singleton) a besoin d'une instance de Simulation, mais qu'aucune autre n'a besoin de récupérer un pointeur (ou une référence dessus), pas la peine de faire de Simulation un Singleton.

Est-ce que quelqu'un aurait une suggestion à propos de mon premier problème qui concerne la manière de communiquer entre deux classes ?

Plusieurs solutions, et une à mon avis à éviter à tout prix : il ne faut pas que ta classe Simulation dépende directement de Affichage, ton modèle doit rester indépendant de la vue. Donc première chose à faire, créer une interface pour l'affichage. Ensuite soit tu décides de créer la simulation depuis la classe Affichage qui s'enregistrera au près de la Simulation, soit tu externalises la construction (dans un builder par exemple) qui sera chargé d'instancier ce qu'il faut et de passer les différentes références/pointeurs comme il faut.

[Dani3L]

Plusieurs solutions, et une à mon avis à éviter à tout prix : il ne faut pas que ta classe Simulation dépende directement de Affichage, ton modèle doit rester indépendant de la vue. Donc première chose à faire, créer une interface pour l'affichage. Ensuite soit tu décides de créer la simulation depuis la classe Affichage qui s'enregistrera au près de la Simulation, soit tu externalises la construction (dans un builder par exemple) qui sera chargé d'instancier ce qu'il faut et de passer les différentes références/pointeurs comme il faut.

Donc si j'ai bien compris, une bonne solution serait d'instancier les deux classes Affichage et Simulation à l'extérieur de celles-ci et de créer une interface dans la classe Affichage (des méthodes publics bien choisies) et de passer un pointeur sur l'instance d'Affichage à l'instance de la classe Simulation. De cette façon lorsque la classe Simulation a besoin de modifier quelque chose lié à l'affichage, elle le fait en passant par l'interface de la classe Affichage.

De plus concernant les classes singletons, il est préférable de créer des classes singletons que d'avoir des classes "statiques" (classes dont les méthodes sont statiques et que l'on utilise sans instanciation).

[bolhrak]

L'interface n'est pas créée "dans" la classe affichage, je faisais plutôt référence à l'héritage. La classe Simulation manipulera un objet de type AffichageInterface par exemple, sans savoir qu'il s'agit en fait d'un objet de type Affichage.

Et oui pour les singletons.

[koala01]

Salut,

Je te conseillerais volontiers de réfléchir correctement aux responsabilités de chaque classe.

Selon moi, ce n'est pas la classe Simulation qui doit demander à la classe Affichage de faire son travail, mais c'est bien à la classe Affichage de demander à la classe Simulation si... elle a des objets à afficher

En effet, l'ordre logique dans lequel les choses pourrait se faire est fort proche de

1. Créer un environnement de simulation
2. Créer les objets nécessaire à la simulation (*)
3. réglages des conditions de simulation (vitesse, particularités de l'environnement telles que gravité, état des routes, température, ...)
4. Lancer l'affichage de la simulation (**)

(*) peut se faire aussi bien avant qu'après le réglage des conditions de simulation
(**)Soit le premier affichage lance la simulation (la classe Affichage lance elle-même un message "start" à la simulation), soit la simulation est lancée avant d'être transmise pour affichage... au choix.

La classe Affichage obtenant un pointeur vers l'instance de Simulation qu'il va devoir gérer et bouclant (une fois la simulation lancée) sur un principe proche de

Code :

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

1
2
3
4
5
6
Tant que simulation non finie
    Obtenir Collection Objets de simulation
    Pour chaque Objet dans Collection
        Afficher Objet
    Fin Pour
Fin Tant

De son coté, la simulation doit

• pouvoir répondre aux messages (en ne considérant que ceux que la classe Affichage va lui envoyer)
  
  • As-tu fini - ou quel est ton état (non débuté/ en cours/ fini)
  • Donne moi ta collection d'objets
  • éventuellement Vas-y (démarre la simulation)
• exposer les comportement
  
  • d'ajout d'objets à la simulation
  • de réglage des conditions de simulation
• disposer de comportements qu'elle garde bien pour elle qui consistent à
  • agir sur les objets qu'elle gère
  • supprimer les objets arrivés "en fin de vie" (voitures "hors course" ou éléments morts, par exemple )

Au final, on se rend compte que la classe Affichage doit disposer de la classe Simulation, mais pas l'inverse