有没有替代混蛋注射的方法？ （又名穷人通过默认构造函数注入）

Question

在少数情况下，我通常很想使用“混蛋注入”。当我有一个“正确的”依赖注入构造函数时：

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

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

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

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

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

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

Answer 1

据我了解，这个问题与如何使用一些适当的默认值公开松散耦合的 API 有关。在这种情况下，你可能有一个很好的Local Default，这种情况下依赖可以被认为是可选的。处理 可选依赖项 的一种方法是使用 Property Injection 而不是 Constructor Injection - 事实上，这是 Property 的海报场景注射。

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

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

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

Answer 2

我的取舍是对@BrokenGlass 的改动：

1) 唯一的构造函数是参数化构造函数

2) 使用工厂方法创建 ThingMaker 并传入该默认源。

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

  public static ThingMaker CreateDefault() {
    return new ThingMaker(new DefaultThingSource());
  }
}

显然，这并不能消除您的依赖关系，但它确实让我更清楚的是，这个对象具有调用者可以深入研究的依赖关系，如果他们愿意的话。如果您喜欢 (CreateThingMakerWithDefaultThingSource)，如果这有助于理解，您可以使该工厂方法更加明确。我更喜欢这个而不是重写 IThingSource 工厂方法，因为它继续支持组合。您还可以在 DefaultThingSource 已过时时添加新的工厂方法，并清楚地找到所有使用 DefaultThingSource 的代码并将其标记为升级。

您在问题中涵盖了各种可能性。其他地方的工厂类是为了方便或类本身的一些方便。唯一没有吸引力的选择是基于反射的，进一步隐藏了依赖关系。

Answer 3

另一种方法是在您的 ThingMaker 类中添加一个 factory method CreateThingSource() 来为您创建依赖项。

对于测试或者如果您确实需要另一种类型的IThingSource，则必须创建ThingMaker 的子类并覆盖CreateThingSource() 以返回您想要的具体类型。显然，这种方法只有在您主要需要能够注入依赖项进行测试时才值得，但对于大多数/所有其他目的不需要另一个 IThingSource

Answer 4

我投票给#3。你会让你的生活——以及其他开发者的生活——变得更轻松。

Answer 5

如果你必须有一个“默认”依赖，也称为穷人的依赖注入，那么你必须在某个地方初始化和“连接”依赖。

我将保留两个构造函数，但有一个工厂仅用于初始化。

public class ThingMaker
{
    private IThingSource _source;

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

    public ThingMaker() : this(ThingFactory.Current.CreateThingSource())
    {
    }
}

现在在工厂中创建默认实例并允许方法被覆盖：

public class ThingFactory
{
    public virtual IThingSource CreateThingSource()
    {
        return new DefaultThingSource();
    }
}

更新：

为什么要使用两个构造函数： 两个构造函数清楚地显示了该类的用途。无参数构造函数声明：只需创建一个实例，该类将执行它的所有职责。现在第二个构造函数声明该类依赖于 IThingSource，并提供了一种使用与默认实现不同的实现方式。

为什么使用工厂： 1- 纪律：创建新实例不应该是此类职责的一部分，工厂类更合适。 2- DRY：想象在同一个 API 中，其他类也依赖于 IThingSource 并做同样的事情。一旦返回 IThingSource 的工厂方法和 API 中的所有类自动开始使用新实例，就重写。

我认为将 ThingMaker 耦合到 IThingSource 的默认实现没有问题，只要此实现对整个 API 有意义，并且您提供了覆盖此依赖项以进行测试和扩展的方法。

Answer 6

您对这种依赖的 OO 杂质感到不满，但您并没有真正说明它最终会导致什么麻烦。

• ThingMaker 是否以任何不符合 IThingSource 的方式使用 DefaultThingSource？没有。
• 是否会在某个时候迫使您停用无参数构造函数？由于您目前能够提供默认实现，因此不太可能。

我认为这里最大的问题是名称的选择，而不是是否使用技术。

Answer 7

通常与这种注入风格相关的示例通常非常简单：“在类B 的默认构造函数中，使用new A() 调用重载构造函数，然后就可以了！”

现实情况是，依赖关系的构建通常极其复杂。例如，如果B 需要像数据库连接或应用程序设置这样的非类依赖项怎么办？然后将B 类绑定到System.Configuration 命名空间，增加其复杂性和耦合性，同时降低其一致性，所有这些都是为了编码可以通过省略默认构造函数简单地外部化的细节。

这种注入风格向读者传达了您已经认识到解耦设计的好处但不愿意投入使用。我们都知道，当有人看到这个多汁、简单、低摩擦的默认构造函数时，他们会调用它，无论从那时起它使他们的程序变得多么僵硬。如果不阅读该默认构造函数的源代码，他们就无法理解其程序的结构，而当您仅分发程序集时，这不是一个选项。您可以记录连接字符串名称和应用程序设置键的约定，但此时代码并不独立，您将责任推给开发人员寻找正确的咒语。

优化代码，这样编写代码的人就可以在不理解他们所说的情况下顺利进行，这是一首警笛歌，一种反模式，最终导致解开魔法所浪费的时间比最初努力节省的时间更多。要么解耦，要么不解耦；在每种模式中保持一只脚会降低两者的焦点。

Answer 8

不管怎样，我在 Java 中看到的所有标准代码都是这样的：

public class ThingMaker  {
    private IThingSource  iThingSource;

    public ThingMaker()  {
        iThingSource = createIThingSource();
    }
    public virtual IThingSource createIThingSource()  {
        return new DefaultThingSource();
    }
}

任何不想要DefaultThingSource 对象的人都可以覆盖createIThingSource。 （如果可能，对createIThingSource 的调用将在构造函数之外的某个地方。）C# 不鼓励像 Java 那样进行覆盖，而且它可能不像在 Java 中那样明显，用户可以并且也许应该提供他们的自己的 IThingSource 实现。 （也不明显如何提供它。）我的猜测是＃3是要走的路，但我想我会提到这一点。

Answer 9

只是一个想法——也许更优雅一点，但遗憾的是并没有摆脱依赖：

• 删除“混蛋构造函数”
• 在标准构造函数中，您将源参数默认为 null
• 然后检查源是否为空，如果是这种情况，则将其分配为“new DefaultThingSource()”，否则无论消费者注入什么

Answer 10

有一个将 DefaultThingSource 映射到 IThingSource 的内部工厂（在您的库内部），该工厂从默认构造函数中调用。

这允许您在没有参数或任何 IThingSource 知识且不直接依赖 DefaultThingSource 的情况下“新建” ThingMaker 类。

Answer 11

对于真正的公共 API，我通常使用两部分方法来处理：

1. 在 API 中创建一个帮助程序，以允许 API 使用者使用他们选择的 IoC 容器从 API 注册“默认”接口实现。
2. 如果希望允许 API 使用者在没有自己的 IoC 容器的情况下使用 API，请在 API 中托管一个填充相同“默认”实现的可选容器。

这里真正棘手的部分是决定何时激活容器 #2，最佳选择方法在很大程度上取决于您的预期 API 使用者。

Answer 12

我支持选项 #1，有一个扩展名：将 DefaultThingSource 设为公共类。您上面的措辞暗示 DefaultThingSource 将对 API 的公共消费者隐藏，但据我了解您的情况，没有理由不公开默认值。此外，您可以轻松记录以下事实：在特殊情况之外，new DefaultThingSource() 始终可以传递给 ThingMaker。