2

私はオブジェクト指向デザインの問題に取り組んでいます。コードを提供するのではなく、混乱している部分に焦点を当てて、テキストで説明しようと思います。

TaxPolicyのリストを含むSalesPolicyというクラスがあります。TaxPolicyは、名前と税率を属性として持つ税政策を表す抽象クラスです。TaxPolicyには、acceptという抽象的なメソッドが含まれています。TaxPolicyの具体的な実装では、acceptメソッドを実装し、TaxPolicyをいつ適用できるかを決定するためのロジックを提供する必要があります。

SalesEngineという別のクラスがあります。SalesEngineにはSalesPolicyがあり、SalesPolicyはSalesEngineコンストラクターのパラメーターの1つです。SalesEngineは、acceptメソッドを呼び出して、SalesPolicyのTaxPolicyのリストからTaxPolicyをアイテムに適用できるかどうかを判断し、それに応じて税金を計算します。前に説明したように、SalesPolicyには、TaxPolicyのリストとリストに追加するメソッドである単一の属性が含まれています。

私が知る必要があるのは、SalesEngineクラスにSalesPolicyのようなパラメーターを設定してもよいかどうかです。テスト可能なコードの観点から、これはどのような影響を及ぼしますか？

4

2 に答える 2

1

このようなシナリオがあれば、まったく問題ないと思います。

public SalesEngine(SalesPolicy policy) { ... }

が作成されているとき、ユーザーまたはユーザーが何を使用したいかをSalesEngineすでに知っている人。SalesPolicy

含める価値のある別のシナリオは、作成時にユーザーが何を使用したいかわからない場合です。これは、デフォルトのコンストラクターとセッターメソッドを追加することで実行できます。SalesPolicySalesEngine

// default construtor
public SalesEngine() { ... }

// sets the sales policy
public void setSalesPolicy(SalesPolicy policy){ ... }
于 2012-08-04T13:29:00.167 に答える
1

私は、あなたの説明が合理的に聞こえるというハンターの答えに同意します（そして、それがどのように使用されるかによっては、SalesPolicyを後で追加できるようにすることが役立つかもしれません）。そこで、ここでテストに関するあなたの質問に答えます。簡単に言えば、実際にはあまり変わらないということです。

SalesEngineがその処理を実行するためにSalesPolicyオブジェクトを必要としていると仮定すると、何らかの方法でそれを取得する必要があります。おそらく、テストの難しさは、SalesPolicyオブジェクトの適切な代表的な範囲をテストすることです。しかし、それをコンストラクターの一部として提供する場合でも、後で追加する場合でも、実際にはそれが簡単になったり難しくなったりすることはありません。

一方、SalesEngineが機能するために必ずしもSalesPolicyを必要としない場合は、Hunterの提案を確実に採用する必要があります。これはより適切なインターフェースであり、SalesPolicyが不要な場合のテストの負担を軽減します。

于 2012-08-04T13:38:48.830 に答える