.net - 什么时候需要接口(interface)？

Question

(在 .NET 的上下文中，它的值(value)是什么)

我倾向于不使用继承，也很少使用接口(interface)。我遇到了一个认为接口(interface)是自吐槽以来最好的东西的人。他到处使用它们。我不明白这一点，因此接下来的问题。我只是想检查一下我对接口(interface)的理解。

如果您在任何地方都在使用界面，我假设您可以预测 future ，您的应用程序需求已确定并且您的应用程序不会发生任何变化。对我来说，尤其是在早期开发过程中，界面成为了拖累。该应用程序在其生命周期中非常动态。如果您需要在界面中减去或添加成员，很多东西都会中断。上面的人说他创建了另一个接口(interface)来处理新成员。什么都没有。

不是组合吗？为什么不使用没有接口(interface)的组合？更灵活。

他如何处理必须从接口(interface)中减去成员的情况？基本上他不会。事情刚刚破裂，这很好，因为现在您可以看到所有受影响的区域并修复它们。与其更优雅地找出所有相关代码路径的位置，不如通过暴力破解类的部分内容？

我将软件应用程序视为图形。完整图是最坏的情况，具有 n(n-1)/2。这意味着每个类(class)都与每个类(class)交谈。令人困惑的蜘蛛网。 n-1 是最好的，其中它们是严格的通信等级。添加另一个接口(interface)只是为了补偿一个新的需要的成员，会在图中添加一个顶点，这意味着更多的边和更强的 n(n-1)/2 方程的实现。没有接口(interface)的组合更像是 mixin。只有选择类使用特定的方法。使用接口(interface)，所有类都被迫使用成员，即使它们不需要它们。组合/混合方法不会添加新的不需要的边缘。

Answer 1

接口(interface)不强制类使用方法。他们强制实现类来实现所有方法，但这是另一回事。

我喜欢接口(interface)将 API 从实现中分离出来的方式。诚然，这也可以通过访问修饰符完成，但接口(interface)使其更清晰。更重要的是，接口(interface)还使模拟变得更容易——这意味着您甚至可以在实现接口(interface)之前对依赖于接口(interface)的类进行单元测试。

是的，这意味着我经常会得到一个只有一个生产实现的接口(interface)。在我看来这不是问题，因为我已经获得了可测试性。

另一方面，我不会为每个类都写一个接口(interface)。我喜欢编写对象本质上提供服务的接口(interface)——身份验证、数据访问等。普通数据对象(即使具有重要行为)在接口(interface)、IME 方面没有那么有用。