c# - 这是使用和测试使用工厂模式的类的正确方法吗？

Question

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

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

这是我需要测试的类:

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);
    }
}

下面是一些基本的接口(interface)定义...

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;
    }
}

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

[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());            
    }
}

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

Answer 1

你问的是一个很长的问题，但这里有一些杂乱的想法:

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

无论如何，引入松散耦合总是会产生开销，但不要认为这样做只是为了可测试性。 Testability is really only the Open/Closed Principle ，因此您可以通过更多方式使代码更加灵活，而不仅仅是启用测试。

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

---

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

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

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

您不需要 DI 容器来完成这一切 - 您可以手动连接实例。这叫做 Pure DI .

当谈到将 ReducerFactory 中的逻辑移动到 CalculationMethod 时，我在考虑虚拟方法。像这样:

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

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

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

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