我的项目中有 200 个类，我应该为每个类创建一个接口吗？

Question

这其实是一个问题 所以当我们在项目中为每个类创建一个接口时 那么当有人新加入时，就很难跟踪流程和类之间的集成

例如：

我有 5 个类，每个类都有一个接口，为了调试我的应用程序中的某些内容，我需要转到第一个类，然后查看哪个接口正在使用和注入，然后转到该接口并查看哪个类正在实现接口？

这比这个场景要困难得多： 我有 5 个类，它们都没有接口，直接注入类（而不是接口） 所以现在我可以更轻松地找到流程。

我在我的项目中做错了？ 我应该只在需要时使用依赖倒置吗？就像 2 个团队之间的联系？

Answer 1

是的，接口调试可能看起来更困难，但这更多的是强耦合或测试不力的项目的症状。接口的使用基于这样的概念：一个类不应依赖于其他类的实现细节 - 仅依赖于它提供的一组公共方法。并且实施不应该依赖于谁使用它。这种方法允许我们以更独立的方式对待每个类，其中单元测试是主要的行为检查工具 - 而不是调试。

例如：

public class Foo {
  private IBar bar;
  
  public Foo(IBar bar) {
    this.bar = bar;
  }

  public FooResult DoSomething() {
    BarResult barResult = this.bar.doWhatBarDoes();
    return this.DoSomethingInternal(barResult);
  }

  private FooResult DoSomethingInternal(BarResult barResult) {
    //some behavior
  }
}

interface IBar {
  public BarResult doWhatBarDoes();
}

public class Bar implements IBar {
  public Bar() {
  }

  public BarResult doWhatBarDoes() {
    //some implementation  
  }
}

public class AnotherBar implements IBar {
  public AnotherBar() {
  }

  public BarResult doWhatBarDoes() {
    //some other implementation  
  }
}

假设您需要在

DoSomething()

类中调试

Foo

的内部。此时您所知道的是，它使用

IBar

实现之一，并检查该行为，您需要检查注入的是哪一个。 但真正的问题是——调试的意义何在？在许多情况下（当然不是所有情况），您要么想要检查

DoSomething()

如何处理

this.bar.doWhatBarDoes();

的结果，要么检查

this.bar.doWhatBarDoes();

本身的执行情况。 对

this.bar.doWhatBarDoes();

本身的检查不应依赖于调用该方法的外部上下文。并且对

DoSomething()

的检查不应依赖于创建

BarResult

的细节（因此使用哪种实现并不重要）。要么是

barResult

的创建有问题，要么是它的使用有问题。 因此，与其在整个过程中进行调试，不如为两个独立功能的单元测试扩展测试用例可能更有用。

所以关于你的标题问题 - 你应该为项目中的每个类创建接口吗？没有明确的正确或错误答案。不要仅仅为了其原理而创建（或不创建）接口，而是更多地关注这样做的后果。调试稍微复杂是缺点之一，但也有很多优点。决定是否（以及何时）使用该界面的能力需要时间和经验来实现。