l'accès aux éléments parent dans un modèle d'objet efficace

Question

J'ai un modèle d'objet suivant:

 
- Book 
-- Chapter 1 
--- Page 1 
---- Image 1 
---- Image 2 
---- Text 1 
--- Page 2 
... 

Les ressources sont en bas au niveau de la page. Mais, j'ai besoin de connaître le chemin complet des ressources, du point de vue des ressources.

Une façon, c'est d'avoir des ressources au courant de leurs parents. Donc, mon objet Image pourrait avoir une propriété "parentPage", qui à son tour pourrait avoir une propriété "parentChapter". De cette façon, je pourrais accéder au chemin complet via currentImage.parentPage.parentChapter. Y a-t-il un meilleur moyen?

Quelques mots sur la raison pour laquelle j'ai besoin de connaître le chemin complet du point de vue d'une ressource. J'ai un modèle d'objet qui est marché et rendu à l'écran. Le moteur de rendu descend du niveau du chapitre jusqu'au niveau élément/ressource (c'est ici que le rendu se produit). Cependant, pour afficher les ressources, j'ai besoin de savoir où elles vivent (c'est-à-dire le chemin réel sur le disque) et cette information est généralement spécifiée au niveau du chapitre.

Merci!

- Éditer - Juste pour clarifier, cette approche parent.parent est-elle la meilleure? Cela oblige les enfants à connaître les parents, ce qui me met mal à l'aise. Couplage?

Answer 1

Que vous utilisiez ou non la structure d'arbre de Zachary ou vous le faites dans un type plus manière spécifique, la question sur le couplage des vies. S'il y a beaucoup de choses sur une image qui n'a rien à voir avec la façon dont l'image est "hébergée" dans une page, vous pouvez utiliser un type intermédiaire qui a l'aspect dépendant du contexte et qui contient une instance d'image (référence). Vous seul pouvez décider si cela est excessif, selon l'application et combien il est important de réduire le couplage et de permettre une plus grande réutilisation de certains constituants dans d'autres contextes.

Answer 2

On dirait que vous voulez un doubly-linked list ou peut-être même envisager d'utiliser un tree structure.

Answer 3

Je suggérerais une structure arborescente, alors que chacune de vos classes hérite d'un nœud d'arbre.

Exemple en C#:

class TreeNode { 
public TreeNode Parent { get; set; } 
public List<TreeNode> Children { get; set; } 
} 

class Book : TreeNode { 
... book attributes ... 
} 

... other classes ... 

En fait, si vous êtes inquiet au sujet de couplage la chose à vous demander est-ce bon ou mauvais couplage couplage? Si le couplage ajoute réellement de la valeur et qu'il y a une raison logique de le faire, faites-le. Sinon, c'est du code gaspillé. Si vous utilisez une langue qui prend en charge des génériques, vous pouvez découpler un peu plus loin:

class TreeNode<TParent, TChild> 
{ 
    public TParent Parent { get; set; } 
    public List<TChild> Children { get; set; } 
} 

class Book : TreeNode<object, Chapter> { } 
class Chapter : TreeNode<Book, Page> { } 
class Page : TreeNode<Chapter, object> { } 

Hope that helps!

Answer 4

Vous pouvez sérialiser l'objet en XML et utiliser linq en XML pour analyser les informations.

Si vous devez utiliser des instances d'objets, une autre option peut être de regarder le motif composite (see wikipedia)

Eric