Question

我刚为其他人提出了以下模式。我已经使用了几次，当我想要为测试注入依赖项的能力时，但仍然希望这个后门（有些）对外人来说是不可见的。因此，空的公共ctor和内部ctor带有参数：

public class ClassThatUseInjection
{
    private readonly SomeClass _injectedClass;

    public ClassThatUseInjection(): this(new SomeClass()) {}

    internal ClassThatUseInjection(SomeClass injectedClass)
    {
        _injectedClass = injectedClass;
    }
}


public class SomeClass
{
    public object SomeProperty { get; set; }
}

我的想法是，由于空的ctor什么都不做，只是向前推进一个新的实例，我的罪行并不算太糟糕。你怎么看？太臭了吗？

此致的Morten

Answer 1

我认为没关系。事实上，你在注入课程时所做的是依赖注入和开放/封闭原则的实际应用我甚至认为将内部人员变成公共人员没有任何伤害我的问题始终是，我不想强迫其他人创建注入类的实例，因此，默认的ctor。但是如果他们想要创建一个实例，他们就可以继续这样做。

在一个相关的说明：恕我直言，你应该使用一个界面而不是一个类，否则，我认为首先传递该类没有太大的优势......

Answer 2

希望这个后门（有点）对外人来说是不可见的

使internal成功完成，IMO。

缺点是它将你的测试放在同一个组件中。

另请参阅Hide public method used to help test a .NET assembly，了解如果您的测试位于外部程序集中，如何隐藏公共方法。

编辑：如果SomeClass在逻辑上是内部的，那么你所做的是特别合适的......如果它是一个不应该/不需要在程序集的公共接口中公开的实现细节。

Answer 3

它被称为“穷人的依赖注射”，如果你不能在你的应用程序中获得一个合适的IOC容器，那么它是一个合理的选择，尽管你会更好地利用容器给你的力量。

吉米·博加德写得很好here

TDD /注入与信息隐藏之间的争斗 - 可能的妥协？

3 个答案: