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

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

以下是一些基本的界面定义......

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

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

Answer 1

这是你要问的一个很长的问题,但这里有一些流浪的想法:

• AFAIK,没有'工厂'模式.有一种称为抽象工厂的模式,另一种称为工厂方法.现在你似乎在使用抽象工厂.
• SomeCalculator没有理由同时拥有a reducerFactory和a reducer字段.摆脱其中一个 - 在您当前的实现中,您不需要该reducer字段.
• reducerFactory只读注入dependency().
• 摆脱默认的构造函数.
• ReducerFactory中的switch语句可能是代码气味.也许您可以将创建方法移动到CalculationMethod类.这实质上将抽象工厂改为工厂方法.

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

是的,要付出很小的代价,但这非常值得.

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

当您决定使用DI时,必须始终如一地使用它.这意味着重载的构造函数是另一种反模式.这使得构造函数模糊不清,并且还可能导致紧耦合和漏泄抽象.

这种级联可能看起来像一个缺点,但实际上是一个优势.当您需要在其他类中创建SomeCalculator的新实例时,您必须再次注入它或注入可以创建它的Abstract Factory.当您从SomeCalculator(例如,ISomeCalculator)中提取接口并注入该接口时,优势就来了.您现在已经有效地将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();
}

这最后的建议是否有意义取决于我没有的大量信息,所以我只是说你应该考虑它 - 在你的具体情况下可能没有意义.