4

在庫システムを設計しています。各在庫品目の税金は、多くの条件（州、郡など）に基づいて計算する必要があります。計算のルールも時間の経過とともに変化します。だから私は戦略パターンを考えていましたが、デザインの説明をするのに豊富な経験がありません。

他にどのような質問をする必要がありますか？

私の在庫アイテムは異なるタイプである可能性があるため、戦略パターンに関するwikiページには次のように記載されています。

クラスの動作は継承されるべきではなく、代わりにインターフェースを使用してカプセル化されるべきです。

これは私の場合にどのように影響しますか？

4

2 に答える 2

4

クラスの動作は継承されるべきではなく、代わりにインターフェースを使用してカプセル化されるべきです。

つまり、Inventory考えられるすべての税計算についてアイテムをサブクラス化するのではなく、インターフェイスの背後で計算アルゴリズムをカプセル化してInventoryから、正しいStrategyオブジェクトを指すクラス内でカプセル化を使用する必要があります。

Inventoryこれにより、新しい計算を行うたびに新しいサブクラスを宣言する必要がなくなるため、多くの作業を節約できます。

次の実装は継承を使用します。

abstract class InventoryBase
{
   protected abstract Money CalculateTax();
}

class InventoryTaxA : InventoryBase
{
   protected override Money CalculateTax()
   {
      // Calculation A
   }
}

class InventoryTaxB : InventoryBase
{
   protected override Money CalculateTax()
   {
      // Calculation B
   }
}

しかし、戦略パターンは次のようになります。

class Inventory
{
   public Inventory(ITaxCalculationStrategy taxCalculationStrategy)
   {
      TaxCalculationStrategy = taxCalculationStrategy;
   }

   protected override Money CalculateTax()
   {
       return TaxCalculationStrategy.Calculate(this);
   }
}

したがって、戦略は、税計算を抽象化するための優れたソリューションです。特定の時間に適用される計算のルールが異なり、変更される可能性がある場合は、ファクトリを使用して正しいStrategyオブジェクトを作成します。

于 2012-04-04T20:24:21.753 に答える
3

設計を少し強化して、税計算のプロセスがどのように行われるか、いつ、誰によって、誰のために、どこに記録されるかを確認する必要があると思います。その責任者は誰でも在庫アイテムを入力として受け取り、アイテム（およびコンテキスト）属性を指定して適用可能な税計算方法を見つける必要があります。そのプロセスには、税計算ポリシーオブジェクトに適切なメソッドを要求することが含まれる場合があります。非常に高いレベルでは、次のようになります。

tax_calculation_method = tax_policy.get_method_for(inventory_item)
tax_value = tax_calculation_method.calculate_for(inventory_item)
tax_account.record_tax(tax_value, for_item: inventory_item)

したがって、戦略パターンは、上記のプロセスを計算方法の詳細 や在庫アイテムを指定して適切な方法を見つける詳細から分離する上で基本的な役割を果たすことができます（したがって、すでに2回使用されています）が、これは実装の詳細にすぎません。全体的なデザインの。いくつか例を挙げると、工場からリポジトリ、または複雑な基準の仕様と複合材料まで、他の多くのパターンが適用される場合があります。

インスピレーションを得るために、いくつかの会計分析パターン（pdf）を見てください。

于 2012-04-04T20:38:32.927 に答える