在少数情况下，我最常被诱惑使用"私生子注射".当我拥有一个"适当的"依赖项注入构造函数时:
public class ThingMaker {
...
public ThingMaker(IThingSource source){
_source = source;
}
但是，对于我预期的public APIs个类(其他开发团队将使用的类)，我再也找不到比编写一个具有最可能需要的依赖关系的默认"混蛋"构造函数更好的 Select 了:
public ThingMaker() : this(new DefaultThingSource()) {}
...
}
这里明显的缺点是，这会创建对DefaultThingSource的静态依赖；理想情况下，不会有这种依赖性，消费者总是会注入他们想要的任何信息源.然而，这太难使用了；消费者希望新成立一家产品制造商，开始生产产品，然后在几个月后需要时注入其他产品.在我看来，这只剩下几个选项:
- 省略不可靠的构造函数；强制ThingMaker的使用者理解IThingSource，了解ThingMaker如何与IThingSource交互，查找或编写一个具体的类，然后在其构造函数调用中注入一个实例.
- 省略构造函数并提供单独的工厂、容器或其他 bootstrap 类/方法；以某种方式让消费者明白，他们不需要编写自己的IThingSource；强迫ThingMaker的消费者找到并理解工厂或 bootstrap 程序并使用它.
- 保留这个构造函数，使使用者能够"新建"一个对象并使用它运行，并处理对DefaultThingSource的可选静态依赖.
天哪，3号看起来确实很吸引人.还有其他更好的 Select 吗？#1或#2似乎不值得.