我通常会在少数情况下使用“混蛋注射”。当我有一个“适当的”依赖项注入构造函数时：

public class ThingMaker {
    ...
    public ThingMaker(IThingSource source){
        _source = source;
    }

但是，对于我打算用作 公共API的 类（其他开发团队将使用的类），我再找不到比编写具有最可能需要的依赖关系的默认“野兽”构造函数更好的选择了：

    public ThingMaker() : this(new DefaultThingSource()) {} 
    ...
}

这里的明显缺点是，这将对DefaultThingSource创建静态依赖关系；理想情况下，不会存在这种依赖关系，并且消费者将始终注入他们想要的任何IThingSource。但是，这太难使用了。消费者想要更换ThingMaker并开始制作事物，然后数月后在需要时注入其他东西。在我看来，这只剩下几个选择：

1. 忽略混蛋构造函数；迫使ThingMaker的使用者了解IThingSource，了解ThingMaker如何与IThingSource交互，查找或编写具体的类，然后在其构造函数调用中插入实例。
2. 省略混蛋构造函数，并提供单独的工厂，容器或其他引导类/方法；以某种方式使消费者了解他们不需要编写自己的IThingSource；迫使ThingMaker的消费者找到并了解工厂或引导者并使用它。
3. 保留混蛋构造函数，使使用者可以“更新”对象并运行它，并处理对DefaultThingSource的可选静态依赖关系。

男孩，＃3肯定看起来很有吸引力。还有其他更好的选择吗？＃1或＃2似乎不值得。