Discussion :

[nonozor]

Bonjour,

Je suis en train d'implémenter une fonction où j'ai créer des classes et des structs pour y stocker les informations dont j'ai besoin:

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
19
20
21
22
23
24
 
struct EdgePart{
    int _ID;
    Edge * _ContainingEgde1;
    Edge * _ContainingEgde2;
  };
 
  struct Edge {
    ListOfEdgePart * _EdgeParts;
    int _NbEdgeParts;
    Area * _Owner;
  };
 
  class Zone{
    int _NumZone;
    IntList _Triangles;
    unsigned int _NbEdges;
    CATBoolean _HasNeighbours;
    int _NbEdges;
    bucketEdge _Edges;
 
    Edge * Absorb( Area * AreaToAbsorb );
    void UpdateEdge();
  };

Pour résumer, il y a des zones en entrées de l'algo, mais qui ne sont pas données par un objet de type "Zone". Mon algo crée alors un objet de type "Zone" par zone, avec les Edge et les EdgePart qui correspondent. Ensuite, des zones en absorbent d'autres, suivant certains critères.

Ma question concerne l'architecture de la fonction:
J'ai mis la fonction "Absord" dans la classe Zone et cela convient pour l'instant mais je me dis qu'il vaudrait mieux que je la mette en tant que méthode d'une classe GestionnaireZones, qui aurait un lien vers toutes les zones, et faire des même pour toutes les fonctions qui modifient les objets "Zone", "Edge" et "EdgePart".

En effet, pour moi les avantages de laisser les méthodes qui modifient un objet en tant que méthode de sa classe sont:
- s'il y a héritage et différentes comportement suivant les classes, mais ce ne sera surement pas le cas ici.
- la modularité, qui permet de modifier le comportement d'une classe sans avoir à modifier le reste, mais ici je pense que tout est un peu trop lié.

Et les désavantages sont:
- il est probable que les critères et le comportement d'absorbion soient modifiés. Par exemple, le choix d'absorber ou non pourrait être influencé par une autre zone et l'absorbtion pourrait modifier les zones voisines. Modifier alors la méthode "Absorb" de la classe "Zone" sera plus difficile que de modifier la méthode "Absorb" de la classe "GestionnaireZone", qui aura déjà accès à toutes les zones.

Qu'en pensez vous?
Mettre toutes les fonctions dans GestionnaireZones ne me parait pas très propre, alors n'hésitez pas à me contredire!!!

[JulienDuSud]

Pourquoi ne pas émettre un prédicat comme quoi une zone possède une tête et une sous-zone ?

De cette manière, tu auras tes sous-zones, et tes super-zones, qui auront en réalité le même type, si le comportement attendu est le même de la part de l'un et de l'autre.

Tout ce que tu auras à gérer, ce sont des pointeurs vers les sous-zones, qui peuvent être des super-zones ou pas. Enfin moi je le verrais comme ça.

Après, tu peux également avoir un vecteur de (pointeur de ) sous-zones dans ta classe zone, qui permettra de vérifier rapidement les sous-zones inclus dans une zone.

Après, bien sûr, tu peux avoir un factory qui permettra de créer des zones pour gérer la mémoire proprement.

[buzzkaido]

Et les désavantages sont:
- il est probable que les critères et le comportement d'absorbion soient modifiés. Par exemple, le choix d'absorber ou non pourrait être influencé par une autre zone et l'absorbtion pourrait modifier les zones voisines. Modifier alors la méthode "Absorb" de la classe "Zone" sera plus difficile que de modifier la méthode "Absorb" de la classe "GestionnaireZone", qui aura déjà accès à toutes les zones.

Moi ça me fait penser au pattern "stratégie" (lien ici)

Je laisserais plutôt la méthode "Absorb" dans la Zone, puisque c'est bien elle qui doit absorber, mais avec un truc du genre :

Code :

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

1
2
3
4
Edge* Absorb(Area* AreaToAbsorb)
{
    return AbsorbStrategyManager::getInstance()->AbsorbZone(this, AreaToAbsorb);
}

Où AbsorbStrategyManager est le gestionnaire de stratégie, implémentée en singleton.

Et dans ce gestionnaire, tu choisit une des IAbsorbStrategy en fonction des zones voisines ou de n'importe quel autre critère.

[nonozor]

Moi ça me fait penser au pattern "stratégie" (lien ici)

Je laisserais plutôt la méthode "Absorb" dans la Zone, puisque c'est bien elle qui doit absorber, mais avec un truc du genre :

Code :

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

1
2
3
4
Edge* Absorb(Area* AreaToAbsorb)
{
    return AbsorbStrategyManager::getInstance()->AbsorbZone(this, AreaToAbsorb);
}

Où AbsorbStrategyManager est le gestionnaire de stratégie, implémentée en singleton.

Et dans ce gestionnaire, tu choisit une des IAbsorbStrategy en fonction des zones voisines ou de n'importe quel autre critère.

Le pattern stratégie parait intéressant, mais il reste le problème que j'ai posé au début: La méthode "Absorb" de Zone a difficilement accès aux informations sur les autres zones. Si l'algo de "Absorb" est modifié et qu'il a besoin de ces informations, ce sera plus compliqué de les lui donner que si il est implémenté dans un GestionnaireZones qui a toutes les infos sur toutes les Zones!
D'autre part, je pense qu'un pattern Strategy pourrait être implémenté dans le GestionnaireZones.

Est ce que quelqu'un pourrait m'expliquer les avantages et désavantages de mettre "Absorb" dans Zone ou dans GestionnaireZone, s'il vous plait?
J'avais dit

En effet, pour moi les avantages de laisser les méthodes qui modifient un objet en tant que méthode de sa classe sont:
- s'il y a héritage et différentes comportement suivant les classes, mais ce ne sera surement pas le cas ici.
- la modularité, qui permet de modifier le comportement d'une classe sans avoir à modifier le reste, mais ici je pense que tout est un peu trop lié.

Et les désavantages sont:
- il est probable que les critères et le comportement d'absorbtion soient modifiés. Par exemple, le choix d'absorber ou non pourrait être influencé par une autre zone et l'absorbtion pourrait modifier les zones voisines. Modifier alors la méthode "Absorb" de la classe "Zone" sera plus difficile que de modifier la méthode "Absorb" de la classe "GestionnaireZone", qui aura déjà accès à toutes les zones.

mais je ne suis vraiment pas fort en Architecture.
N'hésitez pas à me dire si je raconte n'importe quoi!

[buzzkaido]

Si l'algo de "Absorb" est modifié et qu'il a besoin de ces informations, ce sera plus compliqué de les lui donner que si il est implémenté dans un GestionnaireZones qui a toutes les infos sur toutes les Zones!

A mon avis, il te faut effectivement un "GestionnaireZones" qui gere entierement le cycle de vie des zones :

- creation de zones (par exemple, la classe Zone a un constructeur protégé, et est amie du GestionnaireZones, comme ça seul lui peut les créer)
- maintenance de "listes" de zones : par exemple les voisins d'une zone, etc...
- la méthode "creerZone(....)" du gestionnaire crée une zone et l'ajoute dans ses listes
- lorsqu'une zone est modifiée, elle appelle une méthode du style "majZone(this)" sur le GestionnaireZone (en lui passant un pointeur sur la zone modifiée) et le gestionnaire met à jour ses voisin etc...

Ainsi :
- on est assuré que le gestionnaire connait toutes les zones et qu'il maintient à jour les infos de voisinnage etc...
- dans les algos, on n'interroge pas la zone, mais le gestionnaire de zone, du style "getZonesVoisines(Zone* pZone)