问除了私生子注射，还有别的选择吗？(也就是穷人通过默认构造函数的注入)

EN

在少数情况下，我最常使用的是“私生子注射”。当我有一个“合适的”依赖注入构造器时：

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. 保留了专用构造函数，使使用者能够“新建”对象并使用它运行，并处理对make的可选静态依赖

天哪，#3看起来确实很有吸引力。还有其他更好的选择吗？#1或#2似乎不值得。