c# - Dependency Injection 和具体的依赖实现

Question

首先让我介绍一下没有依赖注入(inject)的实现(这会破坏依赖倒置原则):

public class MyValidator
{
  private readonly IChecksumGenerator _checksumGenerator;

  public MyValidator()
  {
     _checksumGenerator = new MyChecksumGenerator();
  }

  ...
}

为了使这段代码可测试，让我们注入(inject) IChecksumGenerator:

public class MyValidator
{
  private readonly IChecksumGenerator _checksumGenerator;

  public MyValidator(IChecksumGenerator checksumGenerator)
  {
    _checksumGenerator = checksumGenerator; 
  }

  ...
}

如果需要，现在我们可以轻松测试 MyValidator 和 stub checksumGenerator。但是 MyValidator 实现在算法上耦合到特定的 IChecksumGenerator 实现(它不会与任何其他实现一起工作)。于是出现了一些问题:

1. 我们引入了一种可能会注入(inject)不正确的 IChecksumGenerator(例如，由于 IoC 容器配置错误)
2. 我们打破了封装，因为 MyValidator 的私有(private)实现细节(耦合到 MyChecksumGenerator)超出了类

我得出的最佳解决方案如下:

public class MyValidator
{
  private readonly IChecksumGenerator _checksumGenerator;

  public MyValidator()
  {
    _checksumGenerator = new MyChecksumGenerator;
  }

  internal MyValidator(IChecksumValidator checksumValidator)
  {
    _checksumValidator = checksumValidator;
  }

  ...
}

在这里，我引入了用于测试目的的特殊构造函数(因此我可以在测试中 stub IChecksumValidator)，但公共(public)构造函数创建了它所耦合的实现(因此封装没有被破坏)。为测试目的创建一些代码有点难看，但在这种情况下看起来很有意义。

你会如何解决这个问题？

Answer 1

重构为构造函数注入(inject)是一个非常好的主意，但我发现问题中提出的约束很奇怪。我建议您重新考虑设计。

如果 MyValidator 仅适用于 IChecksumGenerator 的一种特定实现，它将违反 Liskov Substitution Principle (LSP)。从本质上讲，这也意味着您将无法注入(inject) Test Double。因为 stub/mock/fake/whatever 不会是“正确”的 IChecksumGenerator 的实例。

从某种意义上说，您可以说该 API 与其要求有关，因为它声称它可以处理任何 IChecksumGenerator，而实际上它只适用于一种特定类型 - 我们称它为 OneAndOnlyChecksumGenerator。虽然我建议重新设计应用程序以遵守 LSP，但您也可以更改构造函数签名以诚实地满足要求:

public class MyValidator
{
    private readonly OneAndOnlyChecksumGenerator checksumGenerator;

    public MyValidator(OneAndOnlyChecksumGenerator checksumGenerator)
    {
        this.checksumGenerator = checksumGenerator; 
    }

    // ...
}

您仍然可以通过使战略成员虚拟化来将 OneAndOnlyChecksumGenerator 变成测试替身，这样您就可以创建特定于测试的子类。