0

この単純な分類 (?) の例をモデル化する方法についてアドバイスが必要です:
私は製品を持っています。製品は、ProductType 1、ProductType 2、ProductType 3 などのさまざまなタイプにすることができます。すべての製品には部品番号と名前があります。それらが異なるのは、価格の計算方法です。

  • タイプ 1 の製品の価格は、製品の数によって異なります。したがって、5 つの製品がある場合、価格は $x です。20 個の製品がある場合、価格は $y などになります。
  • タイプ 2 の製品の価格は、各製品の重量によって異なります。重量が 5 kg の場合、価格は $x などになります。
  • タイプ 3 の製品には、各製品の $x のような単純な価格があります。

私の見方では、各「価格構造」には専用のテーブル/クラスが必要です。製品は、製品のタイプに応じて、その価格構造への参照を持ちます。「製品タイプ」テーブルを作成して、製品クラスにタイプという属性を持たせますか?それとも、一般化を使用して、製品 1/2/3 が製品のサブタイプになるようにしますか? 5 種類の料金体系があり、料金の計算方法はタイプごとに異なります。したがって、注文の合計金額を計算するロジックは、各商品タイプに依存します。

これを最良の方法でモデル化する方法についてアドバイスをいただけますか? Product クラスに Type 属性があるアプローチを選択すると、コード内に多数の if-else ステートメントが作成されると思います。それらをサブクラス化することを選択した場合、各クラスは正しい価格を計算するか、または要求されたことは何でも責任を負うことができます。

4

2 に答える 2

1

私の提案は、リレーショナル データ モデルでは、レコード タイプを区別するためのタイプ列を用意することです。コードでは、必ずサブクラス化を使用する必要があります。ドメインモデルは、基礎となるデータモデルから可能な限り独立している必要があり、説明は、属性を共有する必要性を十分にサポートしている必要があります (ABC - 製品の抽象基本クラスを使用)、P1、P2、P3 へのサブタイプ (意味のあるドメイン名を付けます) ）および価格計算を変更するためのポリモーフィズム。

注文は基本製品参照のリストを保持し、合計を取得するには、各製品に価格を尋ね、イテレータを使用してそれらを累積します。

于 2010-08-04T13:43:07.510 に答える
1

これは、ストラテジー パターンを使用する場合の完璧な例のように思えます。クラスの継承を使用して製品の価格設定方法を定義する場合、誰かが後で WidgetXYZ を単純な価格ではなく重量で価格設定する必要があると判断した場合、システム全体を再コンパイルする必要があります。

各製品を「PricingStrategy」を持つものとして定義します。あなたの場合、これは「volumeDiscount」、「byWeight」、または「simple」のいずれかになります。次に、Factoryを使用して、製品の戦略に応じて正しい PriceCalculator オブジェクトを提供できます。その priceCalculator は、それに応じて製品の価格を計算します。

于 2010-08-04T18:48:09.127 に答える