2010-10-28 3 views
0

J'ai la classe A. La classe A est responsable de la gestion de la durée de vie des objets B et contient le conteneur des objets B map<BGuid,B>, et chaque objet B contient le conteneur des objets C map<CGuid,C> .J'ai un global A objet pour l'ensemble de l'application.Recherche des enfants

J'ai le problème suivant: J'ai l'objet CGuid et je veux l'utiliser pour trouver mon objet C. Mais pour cela j'ai aussi besoin de connaître l'objet BGuid qui me dira dans quel objet B je devrais regarder mon objet C. Mais tout ce que j'ai est le CGuid, ce qui signifie que je dois vérifier chaque objet B pour voir s'il contient mon objet C. Cependant je pense que c'est en désordre. Je pensais que peut-être je devrais avoir une autre classe M qui contiendra la carte de tous mes objets C, et je peux y chercher directement avec CGuid, mais cela signifie que je dois maintenir une carte supplémentaire juste pour la recherche.

Aussi, je l'exception à l'avenir ma classe C pour contenir map<Dguid,D> donc j'aurai le même problème pour les objets D, cette fois encore pire, j'aurai besoin de Bguid, Cguid et Dguid pour trouver mon objet D.

Comment résoudre ce problème?

+0

Je veux juste dire que mes GUIDs sont les pointeurs réels aux objets, i.e. BGuid est B * et ainsi de suite. Je ne peux pas changer ça. – user152508

+1

Qu'est-ce qui constitue la "découverte" d'un objet si ce n'est pas un pointeur? – Puppy

+0

Ok, c'est vrai. J'ai mal écrit. J'ai un pointeur vers un autre objet, pas l'objet lui-même. – user152508

Répondre

0

Avez-vous des restrictions sur la mémoire? Sinon, je maintiendrais les tables de recherche inversée (maps), donc vous en avez besoin pour C-> B, quand vous ajoutez D, vous avez besoin d'une seconde D-> C, donc si vous avez C, pour le localiser correctement, vous besoin d'une recherche pour localiser B, puis de A, vous pouvez parcourir vers le bas avec deux autres recherches. Beaucoup plus rapide que de parcourir tous les Bs à la recherche de C!

Une autre alternative, avez-vous le contrôle sur le Guid, si c'est le cas, vous pouvez essayer d'encondiger les informations "path" dans le guid. Dites par exemple que le B guid est "B.1", "B.2", "B.3" etc. le post-fix après '.' Le séparateur vous indique quel B il est. Lorsque vous ajoutez C, vous pouvez simplement ajouter un '.', C'est à dire que C 1 est (supposons qu'il est stocké en B 1) = "B.1.1", alors maintenant pour trouver l'objet, vous analysez la clé, et voila vous avez votre "chemin" vers C1.

0

map<BGuid,B>, map<CGuid,pair<B,C>>, map<DGuid,pair<C,D>>

Avec GUID vous obtenez l'objet et le parent de l'objet. Avec l'objet vous obtenez GUID. Recurse depuis le début.

0

Vous pouvez affecter des plages de GUID enfants à chaque GUID parent. Supposons que BGuid soit dans l'intervalle [0, 9] et CGuid dans l'intervalle [0, 99]. Vous pouvez maintenant mapper dix CGuids à chaque BGuid avec une fonction comme ceci:

mapGuids(B): CGuid => BGuid = B % 10 

Maintenant, vous savez toujours quel chemin prendre à travers l'arbre. Vous voudrez garder votre arbre équilibré pour de meilleures performances quand il y a beaucoup de nœuds.

1

Vous avez une relation classique de Parent - Enfants. Je vous suggère d'améliorer votre conception en ne spécifiant pas comment est géré (c'est-à-dire avec des cartes). utiliser un conteneur pour stocker les enfants et laisser les enfants ont un pointeur vers le parent. De cette façon, il est facile de traverser de n'importe quel point jusqu'au sommet.

Un modèle de conception OOP utile pour ces cas est le CompositePattern

Questions connexes