views:

83

answers:

3

I'm working on a project which has a rich domain-model.

Some of my classes have collections of other types, and those other types have a property that refers back to their 'owner'. This sounds maybe a bit cryptic, so a code example would help:

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;}
}

The question is: what name do you prefer for the 'Product' property of the ProductPrice class ?

Would you name it: - Product (like it is now) - Owner - BelongsTo - something else ?

+1  A: 

Parent is a fairly generic term I often find helpful - but Product works perfectly well too.

Jon Skeet
I find Parent maybe just too generic, and not descriptive enough.Product is fine, but in some cases it feels like 'BelongsTo' is better. Then I think: shouldn't I remain consistent in naming such properties ...
Frederik Gheysels
+2  A: 

Product.

If you have a lot of classes like this, and want to generically follow backrefs, inherit from a HasParent interface that has an abstract method parent(), and have parents inherit for an interface Parent. But other tha following the object graph or by casting, there's not much you can do with a Parent.

EDIT: actually, let me amend that. I worked on a project where we had a semi-complex object graph, and because of some poor planning and some requirements changes, sometimes I'd have to reach across the graph to get a datum from an associated object. ComponentCost to its parent Cost to its parent Item, to its child CustomsInfo to its child ComponentCustomsInfo to its lookup table DutyCalculation. (Yeah, I didn't do the original design, so don't frown at me.)

A parent() method could have made that a little more generic. (Eventually I put together a set of enums (Java enums, so singleton classes) that did traverse the graph for me, in a type safe and even elegant manner. Still, having a parent would have made implementing that simpler.)

tpdi
+2  A: 

Product - there's no ambiguity and the naming is consistent - Product stays Product everywhere.

If accessing the property from outside, I'd prefer having this:

price.Product.Name

than this:

price.Owner.Name
Paulius