c# - C#中依赖注入(inject)和YAGNI混淆的正确使用

Question

我知道你应该依赖于抽象而不是具体的实现，但我也知道 YAGNI原则。有时我发现自己很难调和这两者。

考虑以下类；

public class Foo
{
    public void DoFoo()
    {
    }
    //private foo stuff
}

public class Bar
{
    private readonly Foo _foo;

    public Bar()
    {
        _foo = new Foo();
    }
}

“Bar”是我感兴趣的类；显然有问题，Bar正在实例化Foo的实例，让我重构；

public class Bar
{
    private readonly Foo _foo;

    public Bar(Foo foo)
    {
        _foo = foo;
    }
}

很好，但是 Bar 的构造函数仍然依赖于 Foo，一个具体的实现。我没有得到任何东西(是吗？)。为了解决这个问题，我需要将 foo 抽象化，这就是我的问题开始的地方。

我发现的每个示例总是(可以理解地)演示使用抽象的构造函数注入(inject)。我完全支持防御性编程，但假设我不需要任何其他实现，除了 Foo(测试替身不算在内)。创建一个“IFoo”接口(interface)或“FooBase”抽象类肯定违反了YAGNI原则？我会为 future 可能发生的情况做一些事情，我以后总是可以这样做，例如

public abstract class Foo
{
    public abstract void DoFoo();

    //private foo stuff
}

public class Foo1:Foo
{
    public override void DoFoo()
    {
    }
}

这不会破坏 Bar，我什至可以为一个接口(interface)做这件事，前提是我放弃了“I”约定(我越来越怀疑它)例如

public interface Foo
{
    void DoFoo();
}

public abstract class FooBase:Foo
{
    public abstract void DoFoo();

    //private foo stuff
}

public class Foo1:FooBase
{
    public override void DoFoo()
    {
    }
}

注入(inject)具体实现有什么问题，因为我可以在稍后阶段将其重构为抽象(前提是我为抽象提供与具体实现相同的名称)？

注意:我知道“I”接口(interface)命名约定的论点，这不是我的问题的重点。我也知道将 Foo 设为抽象类会破坏我之前实例化它的代码，但假设我正在广泛使用 DI，所以我只需要更改 DI 容器注册，如果我要介绍 Foo 的新实现。

Answer 1

but Bar's constructor still depends on Foo, a concrete implementation. I haven't gained anything (have I?).

你在这里得到的是当依赖Foo本身有任何依赖关系，或者需要不同的生活方式，您可以进行此更改，而无需对 Foo 的所有消费者进行全面更改。 .

I have no need for any other implementations except Foo (test doubles don't count)

您不能就此忽略单元测试。作为Roy Osherove explained很久以前，您的测试套件是您的应用程序的另一个(同样重要的)消费者，它有自己的要求。如果添加抽象可以简化测试，那么创建它就不需要其他理由了。

To create an "IFoo" interface or a "FooBase" abstract class surely violates the YAGNI principle?

如果您创建此抽象用于测试，则不会违反 YAGNI。在那种情况下，YNI(你需要它)。通过不创建抽象，您可以在生产代码中进行本地优化。这是局部最优而不是全局最优，因为这种优化没有考虑所有其他(同样重要的)需要维护的代码(即您的测试代码)。

What is wrong with injecting a concrete implementation since I can refactor this to an abstraction

尽管如前所述，创建抽象可以简化测试，但注入(inject)具体实例并没有什么错。如果它不简化测试并让消费者对实现产生强烈依赖可能会很好。但请注意，取决于具体类型可能有其缺点。例如，在不更改消费者的情况下，很难用不同的实例(例如拦截器或装饰器)替换它。如果这不是问题，您不妨使用具体类型。