Discussion :

[guiph]

Bonjour,

Voici mon problème.

Je gère des groupes qui contiennent des personnes.
Chaque personne a des objets qui lui sont propres.

ex. :

Code :

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

1
2
3
4
5
groupe 1 --> personne1 --> objet1
                       --> objet2  
         --> personne2 --> objet1
                       --> objet2

Pour chaque niveau j'ai traitements particuliers.

Comment mettre en place une solution me permettant :
1- d'ajouter facilement des traitements ou de les modifier
2- parcourir efficacement c'est à dire le plus rapidement possible

P.S. : j'effectue ce traitement (création de groupe - ajout de personne - ajout d'objet) plusieurs centaines de milliers de fois.
Le but est d'optimiser le traitement !!

Merci.

[mister3957]

Est-ce que tu peux nous donner plus de précision sur les variations ?

Quels sont ces objet1/objet2 ? Personne1/Personne2 ?

Les design pattern agissents plus sur la structure que sur les performances.



Le seul conseil que je peux te donner pour le parcours, c'est d'utiliser le pattern Iterator.

Celà te permet, d'à partir de l'objet 18 d'accéder au suivant, l'objet 19. C'est bête à faire :

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
25
26
27
28
class CPersonne
{
friend class CPersonneIterator;

public:
   //Add / Remove

private:
   std::vector<CObject*> m_vecObjects;
};

class CPersonneIterator
{
public:
   CPersonneIterator(CPersonne& Personne)
       : m_vecIterator(Personne.m_vecObjects.begin())
   {

   }

   CObject* GetObject() { return m_vecIterator == m_Personne.end() ? 0 : *m_vecIterator; }

   bool Next() { return ++m_vecIterator == m_Personne.end(); }
private:
   std::vector<CObject*>::iterator m_vecIterator;
   CPersonne& m_Personne;
};

J'ai pas vérifié la syntaxe.

Tu fais pareil pour les personnes.


Ensuite c'est une question de langage, tu stock et fait transiter les données par pointeur ou référence.

[guiph]

Merci pour l'idée de l'itérator. Ca pourrait déjà me simplifier le parcours.

En simplifiant j'ai :
Groupe :
- code groupe
- nom groupe
- ...

Personne :
- Nom
- Prénom
- Adresse
- ...

Objet
- Code objet
- nom
- ...

Chaque groupe contient de 1 à n personnes.
Chaque personne possède de 1 à n objets.

Je considère pour le moment que tous les groupes ainsi que toutes les personnes ainsi que tous les objets ont la même structure.

J'extrais des données brutes d'une table :

Chaque ligne contient des infos sur le groupe la personne et le produit.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Pour chaque ligne :
  si nouveau groupe
     creer groupe
     ajouter personne
     ajouter objet
  sinon
   si nouvelle personne :
      ajouter personne
      ajouter objet
   sinon ajouter objet

J'effectue une série de traitements sur les données au cours de cette procédure.

A la fin je reparcours cette collection afin d'écrire les données.

Voilà c'est un peu long mais j'espère avoir été clair

[roudoudouduo]

Première question : est ce qu'une personne peut appartenir à plusieurs groupes ? Est ce qu'un objet peut appartenir à plusieurs personne ?

Pour optimiser tu dois rechercher ce qui est réellement couteux dans ton algorithme. Pour avoir travailler de nombreuses fois sur ce type de tâches, il n'est pas évident de prime abbord de trouver la source de lenteur d'un algorithme.

Globalement le code compilé utilisant directement les accès en mémoire est très rapide, et la première optimisation à faire de se trouve plutot sur le nombre d'accès à la persistence.

Par exemple imaginons que tu es un groupe G1 qui contiennent deux personnes P1 et P2 et que le groupe G2 contient également ces deux personnes est ce que tu les recharges de la base de donnée ou est ce que tu les reprends en mémoire.

Il existe des systèmes de persistence très rapide qui permettent d'éviter les accès à la base de donnée trop nombreux (par exemple l'excellent Hibernate).

Globalement avant d'optimiser un module d'accès comme le tiens je te conseille de bétonner ta conception orientée objet. Il est en effet très difficile de maintenir un code réalisé uniquement dans le but d'une optimisation (généralement les développeurs font des choix astucieux mais difficile à expliquer par la suite même pour l'auteur).

A priori dans ton système il y'a trois type d'entités peut-être pourrais tu créer trois accesseurs à ta couche persistence (trois objets ou un seul objet generique) qui se chargerait d'accéder à ta persistence en respectant le règle suivante : une seule méthode charger(IdentOfTheObject) qui charge un objet de la couche persistence et qui le stocke en mémoire. Par la suite si celui-ci est redemandé l'objet se contente de le récupérer en mémoire.

(le code suivant est en java)

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
25
public final class ObjectLoader<T>{
   private final Map buffer = new HashMap<IdentOfTheObject, T>();

   private final ConnexionBase connexion;

   public ObjectLoader(ConnexionBase connexion){
     if(null == connexion){
          throw new NullPointerException();
     }
     this.connexion = connexion;
 }

   public T charger(IdentOfTheObject ident){
      if(null == ident){
           throw new NullPointerException();
      }
     if(buffer.containsKey(ident) == false){
        T object = this.connexion.getObject(ident);
        this.buffer.put(ident, object);
     }
      return buffer.get(ident);
   }

}

Evidemment ce code prend en compte une hypothétique méthode de connexion à la base, mais je peux pas te donner de meilleur exemple, car je n'ai pas plus d'information.

L'autre avantage c'est qu'une modification sur la personne P1 dans G1 modifiera également la personne P1 dans G2

[guiph]

L'idée de la persistance est très bonne mais je ne sais pas dans quelle mesure je peux l'utiliser ici.

En effet, une personne appartient à 1 et 1 seul groupe.

Le problème c'est que des propriétés de mon entité "objet" dépendent de la personne
Ton message me fait penser que j'ai un problème de conception à ce niveau là.
Par exemple mon entité "objet" contient un attribut "date d'obtention". Pour renseigner cet attribut j'ai besoin du nom de la personne...

Donc à ce moment là il m'est impossible de réutiliser l'objet pour une autre personne. Ou alors en partie seulement.

Merci pour l'aide

[mister3957]

Donc c'est comme si en base tu avais une relation n-n que tu souhaitait modéliser par seulement deux tables.

Or, il te faut une table Personne, une table Objet et une table AssocPersonneObjet.

C'est cette dernière table qui possèdera la date d'obtention.


J'ai eu le même soucis y'a pas longtemps, j'ai pas trouvé de meilleure solution que de reproduire 3 classes puis de faire des listes et des pointeurs spécialisés pour reproduire les associations et rester transparent à l'utilisation.

[wiztricks]

Si on reprend:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
Pour chaque ligne :
  si nouveau groupe   <- comment sais-t-on qu'il est nouveau par son nom?
     creer groupe
     ajouter personne  <- quid des personnes qui existent déjà?
     ajouter objet       <- on ajoute l'objet à la personne mais l'objet existe peut être?
  sinon
   si nouvelle personne :
      ajouter personne
      ajouter objet
   sinon ajouter objet

Si les noms des groupes, des personnes et des objets sont "uniques" on peut s'en servir pour récupérer les objets déjà crées (hashtable ou map C++)
=> dans ce cas, inutile de parcourir la liste des objets (au sens OO) crées.

Après la question est comment va-t-on naviguer la dedans?

• groupe -> personnes -> objets?
• objets -> personnes -> groupes?

Dans le premier cas, il serait pertinent d'associer la liste des personnes au groupe alors que dans le second, personne aura un lien au groupe.
Et il n'est pas interdit de faire les deux.

Pour ce qui est de la persistence (base de donnée)... Si de toutes façon on doit traiter un fichier 'plat' en entrée fréquemment, produire les sorties et oublier, je n'en vois pas trop l'intérêt... à moins que la liste soit tellement grande qu'on ne pourra pas la charger en mémoire.

- W

[guiph]

Un grand merci à vous tous.

J'ai opté pour la solution des hashtables avec une classe permettant de faire l'association entre groupe/personne/produit.
Ce qui me permet d'avoir quelque chose de beaucoup plus simple et plus propre qu'avant.

Merci.