当您还需要“默认”具体依赖项时，哪个是更好的依赖注入模式？

Question

为了可测试性，我使用了以下两种模式，但我想知道哪个是更好的 OOP/SOLID。

模式一：提供两个构造函数，其中一个创建具体依赖

public MyClass
{
    private IDependency dependency;

    public MyClass() : this(new ConcreteDependency()) { }

    public MyClass(IDependency dependency)
    {
       this.dependency = dependency;
    }
}

模式2：基类有依赖初始化器，派生类用具体依赖调用它

public abstract MyClassBase
{
    private IDependency dependency;

    protected void Initialize(IDependency dependency)
    {
        this.dependency = dependency;
    }
}


public MyClass : MyClassBase
{
    public MyClass()
    {
       Initialize(new ConcreteDependency());
    }
}

Answer 1

提供的两个示例都展示了 Control Freak 反模式，如 Dependency Injection, Second Edition Principles, Practices, and Patterns 中所述。

Control Freak 反模式出现：

每次您在Composition Root 以外的任何地方依赖易失性依赖。这违反了Dependency Inversion Principle

在第一个示例中，即使 MyClass 使用了 IDependency 抽象，它也会拖着对具体 ConcreteDependency 组件的引用，导致两个类紧密耦合。

在您的第二个示例中发生了同样的紧密耦合，这实际上是相同的反模式。此外，第二个示例甚至使用Initialize 方法将依赖项应用于已创建的MyClassBase 实例。这会导致Temporal Coupling，这本身就是一种代码异味。

适当的解决方案可以防止导致紧密耦合和时间耦合，这意味着您使用构造函数注入并只定义一个构造函数：

public MyClass
{
    private IDependency dependency;

    public MyClass(IDependency dependency)
    {
       this.dependency = dependency ?? throw new ArgumentNullException("dependency");
    }
}

Answer 2

您的两种模式的缺点是它们可能会破坏Dependency Inversion Principle：MyClass 是一个更抽象的东西，但知道ConcreteDependency 这是一个更具体的东西。确实：

1. 无论在何处重复使用 MyClass 类，ConcreteDependency 类都必须可用。
2. 另外，如果你需要将ConcreteDependency更改为ConcreteDependency2，那么你的MyClass类必须更改，这在某些情况下是不好的，例如：有MyClass的客户从不使用它默认构造函数。

更不用说，模式 #2 可能会使您的对象处于意外状态，因为派生类可能会忘记调用 Initialize 方法，除非您的文档非常好。

我建议使用工厂模式：

class Factory {
    public MyClass createDefault() {
        return new MyClass(new ConcreteDependency());
    }
}