我把所有这些接口放在哪里？

Question

我正在尝试通过单元测试来实践。我目前不习惯为类编写接口，除非我预见到某些原因我需要交换不同的实现。好吧，现在我预见到了一个原因：嘲笑。

考虑到我的接口将从少数几个增加到数百个，我脑海中浮现的第一件事是，我应该将所有这些接口放在哪里？我是否只是将它们与所有具体实现混合在一起，还是应该将它们放在子文件夹中。例如，控制器接口应该放在 root/Controllers/Interfaces、root/Controllers 中，还是完全放在其他位置？你有什么建议？

Answer 1

在讨论组织之前：

好吧，现在我预见到一个原因：嘲笑。

您也可以通过类进行模拟。子类化非常适合作为一种选择，而不是总是创建接口。

接口非常有用 - 但我建议仅在有理由创建接口时才创建接口。我经常看到当类可以正常工作并且在逻辑方面更合适时创建接口。您不需要仅仅为了允许自己模拟实现而创建“数百个接口” - 封装和子类化对此非常有效。

话虽如此，我通常会将接口与类一起组织，因为将相关类型分组到相同的命名空间中往往是最有意义的。主要的例外是接口的内部实现 - 这些可以在任何地方，但有时我会创建一个“内部”文件夹+一个内部命名空间，专门用于“私有”接口实现（以及纯粹内部实现的其他类） ）。这有助于我保持主命名空间整洁，因此唯一的类型是与 API 本身相关的主要类型。

Answer 2

这里有一个建议，如果几乎所有接口都只支持一个类，只需将接口添加到与类本身相同的文件中，位于同一名称空间下。这样，您就不会为接口提供单独的文件，这可能会使项目真正混乱，或者只需要一个用于接口的子文件夹。

如果您发现自己使用相同的接口创建不同的类，我会将接口分解到与该类相同的文件夹中，除非它变得完全不守规矩。但我认为不会发生这种情况，因为我怀疑同一文件夹中是否有数百个类文件。如果是这样，应该根据功能对其进行清理和子文件夹，其余的将自行解决。

Answer 3

接口编码远远超出了测试代码的范围。它在代码中创造了灵活性，允许根据产品要求换入或换出不同的实现。

依赖注入是对接口进行编码的另一个好理由。

如果我们有一个名为 Foo 的对象，由十个客户使用，现在客户 x 希望让 Foo 以不同的方式工作。如果我们已编码为接口 (IFoo)，则只需根据 CustomFoo 中的新要求实现 IFoo 即可。只要我们不改变 IFoo 就没有太多需要。客户 x 可以使用新的 CustomFoo，其他客户可以继续使用旧的 Foo，并且需要进行一些其他代码更改来适应。

然而我真正想说的是接口可以帮助消除循环引用。如果我们有一个对象 X 依赖于对象 Y，并且对象 Y 依赖于对象 X。我们有两个选择：1. 对象 x 和 y 必须位于同一个程序集中，或者 2. 我们必须找到某种方法打破循环引用。我们可以通过共享接口而不是共享实现来做到这一点。

/* Monolithic assembly */
public class Foo
{
    IEnumerable <Bar> _bars;
    public void Qux()
    {
       foreach (var bar in _bars)
       {
           bar.Baz();
       }

    }
    /* rest of the implmentation of Foo */
}

public class Bar
{
    Foo _parent;
    public void Baz()
    {
    /* do something here */
    }
    /* rest of the implementation of Bar */
}

如果 foo 和 bar 具有完全不同的用途和依赖关系，我们可能不希望它们位于同一个程序集中，特别是当该程序集已经很大时。

为此，我们可以在其中一个类（例如 Foo）上创建一个接口，并引用 Bar 中的接口。现在我们可以将该界面放入由 Foo 和 Bar 共享的第三个程序集中。

/* Shared Foo Assembly */
public interface IFoo
{
    void Qux();
}

/* Shared Bar Assembly (could be the same as the Shared Foo assembly in some cases) */
public interface IBar
{
    void Baz();
}
/* Foo Assembly */
 public class Foo:IFoo
{
    IEnumerable <IBar> _bars;
    public void Qux()
    {
       foreach (var bar in _bars)
       {
           bar.Baz();
       }

    }
    /* rest of the implementation of Foo */
}
/* Bar assembly */
public class Bar:IBar
{
    IFoo _parent;
    /* rest of the implementation of Bar */
    public void Baz()
    {
        /* do something here */
}

我认为还有一种观点认为，将接口与其实现分开，并在发布周期中以明显不同的方式对待这些接口，因为这允许并非全部针对相同源编译的组件之间的互操作性。如果完全对接口进行编码，并且接口只能针对主要版本增量进行更改，而不能针对次要版本增量进行更改，那么相同主要版本的任何组件都应该与相同主要版本的任何其他组件一起工作，而不管次要版本如何。
通过这种方式，您可以拥有一个发布周期较慢的库项目，其中仅包含接口、枚举和异常。

Answer 4

这取决于。我这样做：如果您必须添加依赖的第 3 方程序集，请将具体版本移至不同的类库。如果没有，它们可以并排放置在同一目录和命名空间中。

Answer 5

我发现当我的项目中需要数百个接口来隔离依赖关系时，我发现我的设计可能存在问题。当许多接口最终只有一种方法时尤其如此。执行此操作的另一种方法是让您的对象引发事件，然后将您的依赖项绑定到这些事件。举个例子，假设您想模拟持久化数据。一种完全合理的方法是这样做：

public interface IDataPersistor
{
    void PersistData(Data data);
}

public class Foo
{
    private IDataPersistor Persistor { get; set; }
    public Foo(IDataPersistor persistor)
    {
        Persistor = persistor;
    }

    // somewhere in the implementation we call Persistor.PersistData(data);

}

另一种无需使用接口或模拟即可做到这一点的方法是这样做：

public class Foo
{
    public event EventHandler<PersistDataEventArgs> OnPersistData;

    // somewhere in the implementation we call OnPersistData(this, new PersistDataEventArgs(data))
}

然后，在我们的测试中，您可以这样做，而不是创建模拟：

Foo foo = new Foo();
foo.OnPersistData += (sender, e) => { // do what your mock would do here };

// finish your test

我发现这是比过度使用模拟更干净。

Answer 6

我非常不同意接受的答案。

1：虽然技术上是正确的，但您不需要接口，因为您可以选择模拟具体实现，但您应该创建一个接口，原因有两个。

您可以使用接口扩展代码，如果您没有扩展，一旦收到更改请求，具体实现需要修改。

1.1:
你可以进行TDD（测试驱动开发），无需任何实际实现的代码，只要创建接口来测试即可。这也将迫使您在实施之前考虑代码设计。这是一种很好的编码方法。

1.2:

但我建议仅在有理由创建界面时才创建界面。我经常看到当类可以正常工作并且在逻辑方面更合适时创建接口。

制作界面总是有原因的。因为 SOLID 的开放/关闭原则表明您应该致力于扩展代码而不是修改它。
出于多种原因，这是事实。

1.2.1：
通过这种方式编写新的单元测试会更容易。您只需要依赖于您在代码中测试的具体实现作为主题。 （在具体实现之前，您可以使用模拟）

1.2.2：
当您有具体的实现时，对该具体实现的引用将在整个系统中传播。有了接口，所有的引用都将通过接口来完成，而不是具体的实现。这使得扩展成为可能。

1.2.3
如果你跟进所有“叶子”代码段，遵循原则，如果方法有返回，则该方法不能有副作用，如果方法没有返回，则只能有 1副作用是，您还会自动将代码拆分为 SOLID 的“S”部分，这使得您的单元测试很小，并且非常易于维护。

2：
如果您想编写干净的代码，从技术上讲，接口是必需的。如果你想遵循 SOLID，我不知道如何在没有界面的情况下做到这一点。

当您打破职责时，您还需要有效地组织代码，因为代码解耦得越多，您将拥有的接口和接口的实现就越多。因此，您需要有一个良好的项目管理系统，这样您就不会随机出现“数百个接口”。

书籍、youtube、udemy 等都有非常好的指南。它们会教你这些。 （还有一些可怜的，基本上，当你必须为它们付费时，它们的有用性就会增加）。如果您打算就此做出商业决策，那么至少在您这样做之前，您必须对主题有足够的了解，以确定免费的是否足够好。