c# - 除了 SCSS 注入(inject)还有其他选择吗？ (又名穷人通过默认构造函数注入(inject))

Question

在某些情况下，我最常想使用“私生子注入(inject)”。当我有一个“适当的”依赖注入(inject)构造函数时:

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

但是，对于我打算用作公共(public) API 的类(其他开发团队将使用的类)，我再也找不到比编写一个默认的“ SCSS ”构造函数更好的选择了- 可能需要的依赖项:

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

这里明显的缺点是这会创建对 DefaultThingSource 的静态依赖；理想情况下，不会有这种依赖关系，消费者总是会注入(inject)他们想要的任何 IThingSource。但是，这太难用了；消费者想要新的 ThingMaker 并开始制作 Things，然后在几个月后需要时注入(inject)其他东西。在我看来，这只剩下几个选项:

1. 省略 SCSS 构造函数；迫使 ThingMaker 的消费者了解 IThingSource，了解 ThingMaker 如何与 IThingSource 交互，找到或编写一个具体的类，然后在他们的构造函数调用中注入(inject)一个实例。
2. 省略 SCSS 构造函数并提供单独的工厂、容器或其他引导类/方法；以某种方式让消费者明白他们不需要编写自己的 IThingSource；迫使 ThingMaker 的消费者找到并了解工厂或 Bootstrap 并使用它。
3. 保留 SCSS 构造函数，使消费者能够“新建”一个对象并使用它运行，并处理对 DefaultThingSource 的可选静态依赖。

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

Answer 1

据我了解，这个问题涉及如何公开具有一些适当默认值的松耦合 API。在这种情况下，您可能有一个很好的 Local Default，在这种情况下，依赖项可以被视为可选的。处理可选依赖项的一种方法是使用属性注入(inject)而不是构造函数注入(inject) - 事实上，这是属性的海报场景注入(inject)。

但是，当默认值是外部默认值 时，Bastard Injection 的真正危险在于，因为这意味着默认构造函数会拖拽一个不需要的耦合到实现默认值的程序集。然而，据我了解这个问题，预期的默认值将源自同一个程序集，在这种情况下我看不到任何特别的危险。

在任何情况下，您也可以考虑我之前的一个回答中描述的 Facade:Dependency Inject (DI) "friendly" library

顺便说一句，这里使用的术语是基于来自 my book 的模式语言.