Comment nommez-vous les propriétés 'back-reference'?

Question

Je travaille sur un projet qui a un modèle de domaine riche.

Certaines de mes classes ont des collections d'autres types, et ces autres types ont une propriété qui renvoie à leur 'propriétaire'. Cela semble peut-être un peu cryptique, donc un exemple de code serait utile:

public class Product 
{ 
    private IList<ProductPrice> _prices = new List<ProductPrice>(); 

    public void AddPrice(ProductPrice price) 
    { 
     price.Product = this; 
     _prices.Add (price); 
    } 
} 

public class ProductPrice 
{ 
    public DateTime ValidationDate {get; set;} 
    public Decimal Price {get; set;} 
    public Product Product {get; set;} 
} 

La question est: quel nom préférez-vous pour la propriété « produit » de la classe ProductPrice?

Voulez-vous le nom: - Produit (comme il est maintenant) - Propriétaire - Appartient - autre chose?

Answer 1

Produit - il n'y a pas d'ambiguïté et la dénomination est cohérente - Le produit reste Produit partout.

Si l'accès à la propriété de l'extérieur, je préfère avoir ceci:

price.Product.Name 

que ceci:

price.Owner.Name 

Answer 2

Parent est un terme assez générique que je trouve souvent utile - mais Product fonctionne parfaitement bien aussi.

Answer 3

Produit.

Si vous avez beaucoup de classes comme ça, et que vous voulez suivre de manière générique backrefs, héritez d'une interface HasParent qui a une méthode abstraite parent(), et dont les parents héritent d'une interface Parent. Mais d'autre part, en suivant le graphique de l'objet ou en lançant, il n'y a pas grand-chose à faire avec un Parent.

EDIT: en fait, permettez-moi de modifier cela. J'ai travaillé sur un projet où nous avions un graphe d'objets semi-complexe, et à cause d'une mauvaise planification et de quelques changements d'exigences, il fallait parfois traverser le graphe pour obtenir une donnée d'un objet associé. ComponentCost à son parent Coût à son élément parent Item, à son enfant CustomsInfo à son enfant ComponentCustomsInfo à sa table de conversion DutyCalculation. (Oui, je n'ai pas fait la conception originale, alors ne me froncez pas les sourcils.)

Une méthode parent() aurait pu rendre cela un peu plus générique. (Finalement, j'ai mis en place un ensemble d'énumérations (enums Java, donc des classes singleton) qui ont traversé le graphique pour moi, d'une manière sûre et élégante, mais avoir un parent aurait rendu l'implémentation plus simple.)