2

我正在研究一个面向对象的设计问题。我将尝试专注于我感到困惑的部分，并用文字解释它，而不是提供代码。

I have a class called SalesPolicy that contains a List of TaxPolicy. TaxPolicy is an abstract class that represents a tax policy with name and tax rate as attributes. TaxPolicy contains an abstract method called accept. Concrete implementations of a TaxPolicy must implement the accept method and provide the logic for deciding when a TaxPolicy is applicable.

I have another class called SalesEngine. SalesEngine has a SalesPolicy and SalesPolicy is one of the parameters to the SalesEngine constructor. SalesEngine decides whether a TaxPolicy from a List of TaxPolicy in SalesPolicy is applicable for an item or not by calling the accept method and then calculates the tax accordingly. As explained earlier, SalesPolicy contains a single attribute which is a list of TaxPolicy and a method to add to the List.

我需要知道的是是否可以为 SalesEngine 类设置像 SalesPolicy 这样的参数。从可测试代码的角度来看，这有什么影响？

4

2 回答 2

1

我认为有这样的场景是完全可以的：

public SalesEngine(SalesPolicy policy) { ... }

创建SalesEngine用户或已经知道SalesPolicy他们想要使用什么的人的位置。

另一个可能有价值的场景是用户在创建时不知道SalesPolicy他们想要使用什么的情况SalesEngine，您可以通过添加默认构造函数和 setter 方法来做到这一点：

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

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

我同意 Hunter 的回答，即您的描述听起来很合理（并且，根据它的使用方式，允许稍后添加 SalesPolicy 可能会很有用）。所以在这里我将解决你关于测试的问题。简短的回答是，它并没有真正改变太多。

假设 SalesEngine 需要一个 SalesPolicy 对象来完成它的工作，它必须以一种或另一种方式获得它。据推测，测试困难将在于测试具有良好代表性的 SalesPolicy 对象范围。但是，无论您是将其作为构造函数的一部分还是稍后添加，都不会真正使这变得更容易或更难。

另一方面，如果 SalesEngine 并不总是需要 SalesPolicy 才能工作，那么您绝对应该采纳 Hunter 的建议。这将是一个更合适的接口，并且在不需要 SalesPolicy 的情况下可以减轻测试负担。

于 2012-08-04T13:38:48.830 回答