2

我对工厂模式没有太多经验，我遇到过一个我认为有必要但我不确定我是否正确实现了该模式并且我担心它的影响的场景对我的单元测试的可读性有影响。

我创建了一个代码片段，它近似（从内存中）我正在工作的场景的本质。如果有人可以看看它，看看我所做的是否合理，我将不胜感激。

这是我需要测试的课程：

public class SomeCalculator : ICalculateSomething
{
    private readonly IReducerFactory reducerFactory;
    private IReducer reducer;

    public SomeCalculator(IReducerFactory reducerFactory)
    {
        this.reducerFactory = reducerFactory;
    }

    public SomeCalculator() : this(new ReducerFactory()){}

    public decimal Calculate(SomeObject so)
    {   
        reducer = reducerFactory.Create(so.CalculationMethod);

        decimal calculatedAmount = so.Amount * so.Amount;

        return reducer.Reduce(so, calculatedAmount);
    }
}

以下是一些基本的接口定义......

public interface ICalculateSomething
{
    decimal Calculate(SomeObject so);
}

public interface IReducerFactory
{
    IReducer Create(CalculationMethod cm);
}

public interface IReducer
{
    decimal Reduce(SomeObject so, decimal amount);
}

这是我创建的工厂。我目前的要求让我添加了一个特定的 Reducer MethodAReducer 以用于特定场景，这就是我尝试引入工厂的原因。

public class ReducerFactory : IReducerFactory
{
    public IReducer Create(CalculationMethod cm)
    {
        switch(cm.Method)
        {
            case CalculationMethod.MethodA:
                return new MethodAReducer();
                break;
            default:
                return DefaultMethodReducer();
                break;
        }
    }
}

这些是两种实现的近似值......实现的本质是，如果对象处于特定状态，它只会减少数量。

public class MethodAReducer : IReducer
{
    public decimal Reduce(SomeObject so, decimal amount)
    {   
        if(so.isReductionApplicable())
        {
            return so.Amount-5;
        }
        return amount;
    }
}

public class DefaultMethodReducer : IReducer
{
    public decimal Reduce(SomeObject so, decimal amount)
    {
        if(so.isReductionApplicable())
        {
            return so.Amount--;
        }
        return amount;
    }
}

这是我正在使用的测试夹具。让我担心的是工厂模式在测试中占用了多少空间，以及它似乎如何降低测试的可读性。请记住，在我的真实世界课程中，我有几个需要模拟的依赖项，这意味着这里的测试比我的真实世界测试所需的要短几行。

[TestFixture]
public class SomeCalculatorTests
{
    private Mock<IReducerFactory> reducerFactory;
    private SomeCalculator someCalculator;

    [Setup]
    public void Setup()
    {
        reducerFactory = new Mock<IReducerFactory>();
        someCalculator = new SomeCalculator(reducerFactory.Object);     
    }

    [Teardown]
    public void Teardown(){}

第一次测试

    //verify that we can calculate an amount
    [Test]
    public void Calculate_CalculateTheAmount_ReturnsTheAmount()
    {
        decimal amount = 10;
        decimal expectedAmount = 100;
        SomeObject so = new SomeObjectBuilder()
         .WithCalculationMethod(new CalculationMethodBuilder())                                                          
                     .WithAmount(amount);

        Mock<IReducer> reducer = new Mock<IReducer>();

        reducer
            .Setup(p => p.Reduce(so, expectedAmount))
            .Returns(expectedAmount);

        reducerFactory
            .Setup(p => p.Create(It.IsAny<CalculationMethod>))
            .Returns(reducer);

        decimal actualAmount = someCalculator.Calculate(so);

        Assert.That(actualAmount, Is.EqualTo(expectedAmount));
    }

第二次测试

    //Verify that we make the call to reduce the calculated amount
    [Test]
    public void Calculate_CalculateTheAmount_ReducesTheAmount()
    {
        decimal amount = 10;
        decimal expectedAmount = 100;
        SomeObject so = new SomeObjectBuilder()
         .WithCalculationMethod(new CalculationMethodBuilder())                                                          
                     .WithAmount(amount);

        Mock<IReducer> reducer = new Mock<IReducer>();

        reducer
            .Setup(p => p.Reduce(so, expectedAmount))
            .Returns(expectedAmount);

        reducerFactory
            .Setup(p => p.Create(It.IsAny<CalculationMethod>))
            .Returns(reducer);

        decimal actualAmount = someCalculator.Calculate(so);

        reducer.Verify(p => p.Reduce(so, expectedAmount), Times.Once());            
    }
}

那么所有这些看起来都正确吗？或者有没有更好的方法来使用工厂模式？

4

1 回答 1

9

这是一个很长的问题，但这里有一些杂散的想法：

  • AFAIK，没有“工厂”模式。有一种称为Abstract Factory的模式和另一种称为Factory Method的模式。现在你似乎在使用抽象工厂。
  • SomeCalculator 没有理由同时具有 areducerFactory和 areducer字段。摆脱其中之一 - 在您当前的实现中，您不需要该reducer字段。
  • 将注入的依赖项 ( reducerFactory) 设为只读。
  • 摆脱默认构造函数。
  • ReducerFactory 中的 switch 语句可能是代码异味。也许您可以将创建方法移至 CalculationMethod 类。这本质上会将抽象工厂更改为工厂方法。

在任何情况下，引入松散耦合总是有相关的开销，但不要认为您这样做只是为了可测试性。可测试性实际上只是开放/封闭原则，因此您正在以更多方式使您的代码更加灵活，而不仅仅是为了启用测试。

是的，要为此付出很小的代价，但这是非常值得的。

在大多数情况下，注入的依赖项应该是只读的。虽然技术上没有必要，但使用 C#readonly关键字标记字段是一个很好的额外安全级别。

当您决定使用 DI 时，您必须始终如一地使用它。这意味着重载的构造函数是另一种反模式。这使得构造函数模棱两可，也可能导致紧耦合和泄漏抽象。

这级联并且可能看起来像一个缺点，但实际上是一个优势。当您需要在其他类中创建 SomeCalculator 的新实例时，您必须再次注入它或注入可以创建它的抽象工厂。当您从 SomeCalculator（例如，ISomeCalculator）中提取接口并注入它时，优势就来了。您现在已经有效地将 SomeCalculator 的客户端与 IReducer 和 IReducerFactory 分离。

您不需要 DI 容器来执行所有这些操作 - 您可以手动连接实例。这称为纯 DI。

当谈到将 ReducerFactory 中的逻辑移动到 CalculationMethod 时，我正在考虑一个虚拟方法。像这样的东西：

public virtual IReducer CreateReducer()
{
    return new DefaultMethodReducer();
}

对于特殊的 CalculationMethods，您可以覆盖 CreateReducer 方法并返回不同的 reducer：

public override IReducer CreateReducer()
{
    return new MethodAReducer();
}

最后一条建议是否有意义取决于我没有的很多信息，所以我只是说你应该考虑它——在你的具体情况下它可能没有意义。

于 2009-12-12T07:11:34.393 回答