Discussion :

[jenesuispasunrobot]

Bonjour à tous,

J'ai une petite question concernant une architecture et je ne sais pas quel choix faire. Je suis en train de développer un petit jeu et j'ai plusieurs objets :

-Pays

-Ville

-Engine

L'objet Engine contient tout le code fonctionnel, et gère les interactions du jeu. Je souhaiterais par exemple que lorsque la population d'un pays ou d'une ville tombe à 0 déclencher un événement que je pourrais binder avec ma couche contrôle.

Mon problème est de savoir ou situer les événements. Est-il plus simple qu'ils soient tous gérés au niveau du moteur de jeu (Engine) ou gérés au niveau de chaque objet (Pays, Ville et autres) ?

Merci pour votre réponse.

[chaplin]

Ton problème me fait penser aux éléctions présidentielles.

[_IpC_]

Il n'y a pas beaucoup de détails, mais apparemment le "coté fonctionnel" de ton application se situera dans Engine, et Pays et Ville ne sont que le modèle (données).
Pour moi, il faudrait donc que ce soit géré dans Engine. Après je ne sais pas si c'est la solution la plus simple, mais c'est celle qui me parait le plus logique. Après, ça dépend du contexte et de l'action déclenchée ...

ps : tu parle de "couche contrôle" ... utilises-tu un modèle MVC ?

[jenesuispasunrobot]

Merci pour vos réponses.

Je vais essayer d'être plus explicite:

Pays et Ville sont des Entités Métiers qui contiennent des informations telles que la population (Je pense y ajouter des méthodes qui concernent uniquement ces objets)

Engine est un contrôleur métier (désolé, je ne sais pas si j'utilise bien les bon termes, auto-didacte inside) qui sert de "colle" à tout les objets et réalise les traitements (tour de jeu, etc)

Imaginons que la population d'un pays tombe à 0, la question est de savoir est ce que je met un événement dans mon objet Pays qui sera appelé dans le setter de ma propriété lorsque cette valeur va tomber à 0, ou est ce que je le met dans mon objet Engine lorsque je réalise cette soustraction...

Cet événement va ensuite servir pour la couche graphique qui sera réalisée plus tard.

[chaplin]

Merci pour vos réponses.

Je vais essayer d'être plus explicite:

Pays et Ville sont des Entités Métiers qui contiennent des informations telles que la population (Je pense y ajouter des méthodes qui concernent uniquement ces objets)

J'utiliserais un pattern Observer sur la classe population sachant qu'un Pays a une population qui est composée de populations de ville. En poussant le bouchon, ou pourrait imaginer qu'un "empire" soit composé de plusieurs pays et que les villes soient composées de quartier, ce qui introduirait une hierarchie pour ne pas dire une composition.

[jenesuispasunrobot]

J'utiliserais un pattern Observer sur la classe population sachant qu'un Pays a une population qui est composée de populations de ville. En poussant le bouchon, ou pourrait imaginer qu'un "empire" soit composé de plusieurs pays et que les villes soient composées de quartier, ce qui introduirait une hierarchie pour ne pas dire une composition.

Pour ce qui est des villes et des quartiers, j'ai déjà pensé cela puisque villes et pays dérivent de la même classe "EntiteGeographique".

Pour ce qui est du pattern observer c'est obligatoirement le cas en C# si tu utilise les events si je ne m'abuse ? et oui, au fait, c'est du c#

donc selon toi il faudrait placer les événements au niveau des EM.

[chaplin]

Oui, une classe métier doit regrouper toutes les méthodes qui ont attrait au métier.

Un population, c'est un nombre d'habitants, si le nombre d'habitants d'une ville change, automatiquement celui d'un pays change, donc pays ou plutôt l'objet population de Pays doit être averti par le biais d'un événement déclenché au niveau d'un objet population de ville.

C'est ma façon de voir le problème, il y en a d'autres.

Pour les événements en C#, je pense qu'il s'agit plus de delegates.

[_IpC_]

En effet, le pattern observer est une bonne solution, mais personnellement je trouve ça un peu lourd. Après cela dépend.
Si dans ton application, et plus particulièrement dans ton contrôleur on retrouve plusieurs soustraction de la population des villes, tu gagnera sûrement du temps, et gagnera en modularité en évitant les copier/coller et permettant une évolution éventuelle.
En revanche, si tu n'effectue cette soustraction dans une seule méthode, et que ceci est fixe et déterminé, alors je pense que tu devrais effectuer la vérification dans Engine, au moment de la soustraction.

[jenesuispasunrobot]

Oui, une classe métier doit regrouper toutes les méthodes qui ont attrait au métier.

Un population, c'est un nombre d'habitants, si le nombre d'habitants d'une ville change, automatiquement celui d'un pays change, donc pays ou plutôt l'objet population de Pays doit être averti par le biais d'un événement déclenché au niveau d'un objet population de ville.

C'est aussi une partie de mon soucis car la population se compose de la population du pays, j'entends par là de la campagne et de la population de la ville...

j'ai donc mes 2 classes Pays et ville dérivées d'EntiteGeographique qui a une propriété "population"

la population de pays ne contient pas la population de la ville car se sont 2 entités séparées ! Ou alors je devrait peut-être créer une entité intermédiaire avec

Pays ==> campagne
|==> Ville

Mais j'ai peur que ça fasse un peu lourd. Je ne vais pas aller trop dans le détail mais toute la population qui est soustraite (décède) de mon pays est stockée dans un autre objet inclus dans le pays. J'ai ensuite des méthodes au niveau de mon objet EntiteGeographique qui me donne la population totale (cumul pays + ville) ainsi que la population décédée (cumul des habitants décédés stockées dans des collectes affectés au pays et aux villes).

[chaplin]

C'est aussi une partie de mon soucis car la population se compose de la population du pays, j'entends par là de la campagne et de la population de la ville...

la population de pays ne contient pas la population de la ville car se sont 2 entités séparées !

Je ne comprends pas

Pays = ville + campagne (???)

[jenesuispasunrobot]

Non, à l'heure actuelle il y a uniquement pays et ville.

la population de "pays" représente la population de la campagne...

[_IpC_]

D'accord, donc si j'ai bien compris :
- il te faut vérifier que la valeur de retour d'une méthode d'EntiteGeographique est supérieur à 0.
- Cette méthode fait la somme des propriétés population d'un Pays et d'une (ou plusieurs ?) Ville (contenues dans le pays ?).
- EntiteGeographique sert ici uniquement de classe mère. Il n'y a aucune relation d'aggrégation ou de composition entre elle et Pays et/ou Ville

Si c'est exact, alors il me semble que ce soit au contrôleur de vérifier.
De plus, je pense que la méthode permettant de calculer la population d'un pays doit se trouver dans la classe Pays et pas dans EntiteGeographique : ta classe Ville ne devrait pas, et n'a pas besoin d'avoir accès à cette méthode. Et je renommerai l'attribut 'population' de Pays en 'populationCampagne' car la ça évoque vraiment la population totale du pays.

[jenesuispasunrobot]

Parfait, je vois mieux maintenant !

Je vais effectivement placer les événements au niveau de Engine, ça semble plus logique.

[jenesuispasunrobot]

Et pour finir de compléter la gestion des villes et des pays, j'ai modifié sensiblement l'organisation. auparavant il y avait la chose suivante:

Code :

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

1
2
pays: EntiteGeographique
  private List<Ville> Villes;

maintenant j'ai modifié de manière à avoir directement dans EntiteGeographique un élément:

Code :

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

1
2
EntiteGeographique
  private List<EntiteGeographique> SousEntites;

De cette manière je ne suis pas limité par la profondeur de l'intrication que je pourrais avoir par la suite, par exemple Pays=> Région => Départements => Villes