2009-04-07 11 views
0

私は豊富なドメインモデルを持つプロジェクトに取り組んでいます。「バックリファレンス」プロパティの名前はどのようにしますか?

私のクラスには他のタイプのコレクションがあり、他のタイプには '所有者'を参照するプロパティがあります。

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

質問です:あなたはProductPriceクラスの「製品」プロパティのために好むん何名 これには、コード例が役立つだろう、多分少し不可解に聞こえますか?

は、あなたはそれに名前を付けるだろう: - 製品(それは今のような) - 所有者 - belongsToの - 他の何か?

答えて

2

製品 - あいまいさがなく、命名は一貫しています - 製品はどこにでも存在します。

外からプロパティにアクセスする場合、私はこの持つ好む:私は親多分あまりにも汎用的ではなく、十分な記述を見つける

price.Owner.Name 
1

Parent私はしばしば参考になるかなり一般的な用語ですが、Productも完璧に機能します。

+0

:これより

price.Product.Name 

を。 製品は問題ありませんが、場合によっては、「BelongsTo」が優れているように感じます。それでは、私はそのような特性の命名に一貫していてはならないと思います... –

2

製品。

このようなクラスがたくさんあり、バックレファレンスを一般的に従いたい場合、抽象メソッドparent()を持つHas​​Parentインターフェイスから継承し、親がインターフェイスParentを継承するようにします。しかし、オブジェクトグラフに従うか、キャスティングすることによって、親とはあまり関係がありません。

EDIT:実際には、私はそれを修正させてください。私は、半複雑なオブジェクトグラフを持っていたプロジェクトに取り組んでいました。計画の不備や要件の変更があったため、関連するオブジェクトからデータを取得するためにグラフ全体に到達する必要がありました。 ComponentCostをその親項目へ、その親項目へ、その子CustomsInfoへ、子ComponentCustomsInfoへ、そのルックアップテーブルDutyCalculationへ。 (ええ、私は元のデザインをしていなかったので、私に眉をひそめてはいけません。)

parent()メソッドは少し一般的なものにすることができました。 (最終的には、私のためにグラフを横断した列挙型(Javaのenum、つまりシングルトンクラス)の集合を型安全でエレガントな方法でまとめましたが、それでも親があれば簡単に実装できました)

関連する問題