有没有替代私生子注射的方法?(又名穷人通过默认构造函数注入)

问题描述

在少数情况下，我最常倾向于使用混蛋注射".当我有一个正确的"依赖注入构造函数时:

I most commonly am tempted to use "bastard injection" in a few cases. When I have a "proper" dependency-injection constructor:

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

但是，对于我打算作为公共 API(其他开发团队将使用的类)的类，我找不到比编写默认的混蛋"构造函数更好的选择了- 可能需要的依赖:

But then, for classes I am intending as public APIs (classes that other development teams will consume), I can never find a better option than to write a default "bastard" constructor with the most-likely needed dependency:

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

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

The obvious drawback here is that this creates a static dependency on DefaultThingSource; ideally, there would be no such dependency, and the consumer would always inject whatever IThingSource they wanted. However, this is too hard to use; consumers want to new up a ThingMaker and get to work making Things, then months later inject something else when the need arises. This leaves just a few options in my opinion:

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

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

Boy, #3 sure seems attractive. Is there another, better option? #1 or #2 just don't seem worth it.

推荐答案

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

As far as I understand, this question relates to how to expose a loosely coupled API with some appropriate defaults. In this case, you may have a good Local Default, in which case the dependency can be regarded as optional. One way to deal with optional dependencies is to use Property Injection instead of Constructor Injection - in fact, this is sort of the poster scenario for Property Injection.

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

However, the real danger of Bastard Injection is when the default is a Foreign Default, because that would mean that the default constructor drags along an undesirable coupling to the assembly implementing the default. As I understand this question, however, the intended default would originate in the same assembly, in which case I don't see any particular danger.

在任何情况下，您也可以考虑我之前的一个答案中描述的 Facade:依赖注入(DI)友好"图书馆

In any case you might also consider a Facade as described in one of my earlier answers: Dependency Inject (DI) "friendly" library

顺便说一句，这里使用的术语基于我的书中的模式语言.

BTW, the terminology used here is based on the pattern language from my book.

这篇关于有没有替代私生子注射的方法?(又名穷人通过默认构造函数注入)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！