Question

我注意到一些程序员喜欢为他们所有的类创建接口。我喜欢某些事物的接口（例如检查对象是否支持某种行为，然后为该行为设置接口）但过度使用接口有时会使代码膨胀。当我将方法或属性声明为public时，我希望人们只使用我的具体类，我并不真正理解在此基础上创建接口的必要性。

我想听听你对界面的看法。你何时使用它们以及用于何种目的？

谢谢。

Answer 1

不假思索地应用任何类型的设计模式或想法，只是因为有人告诉你这是一个好习惯，这是一个坏主意。

该课程包括为您创建的每个课程创建单独的界面。你应该至少能够为每一个设计决定提供充分的理由，并且“因为乔说这是好的做法”并不是一个足够好的理由。

接口适用于将某些代码单元的接口与其实现分离。创建接口的一个原因是因为您预见到将来可能会有多个实现。它还可以帮助进行单元测试;您可以对要测试的单元所依赖的服务进行模拟实现，并将模拟实现插入而不是“真实的”进行测试。

Answer 2

接口是一种强大的抽象工具。有了它们，您可以更自由地替换（例如）测试类，从而解耦您的代码。它们也是缩小代码范围的一种方法;您可能不需要特定位置的给定类的完整功能集 - 您需要哪些功能？这是一种以客户为中心的思考接口的方式。

Answer 3

单元测试。

使用描述所有类方法和属性的接口，可以通过单击来创建模型类，以模拟不在所述测试范围内的行为。

Answer 4

这都是关于期待和为变革做准备的。

一些使用的方法（我不一定提倡它）是创建IThing和ThingFactory。

所有代码都将引用IThing（而不是ConcreteThing）。所有对象创建都可以通过Factory Method完成。

ThingFactory.CreateThing（某些参数）。

所以，今天我们只有AmericanConcreteThing。可能性是我们可能永远不会需要另一个。但是，如果经验教会了我什么，那就是我们总是需要另一个。

您可能不需要EuropeanThing，但TexasAmericanThing是一种独特的可能性。

因此，为了尽量减少对代码的影响，我可以将创建行更改为：

ThingFactory.CreateThing（帐户）并创建我的班级TexasAmericanThing：IThing。

除了构建课程外，唯一的变化是ThingFactory，需要更改

public static IThing CreateThing(Account a)
{ 
   return new AmericanThing();
}

to 

public static IThing CreateThing(Account a)
{
   if (a.State == State.TEXAS) return new TexasAmericanThing();
   return new AmericanThing();
}

Answer 5

我自己也见过很多盲目的界面。但是，当智能地使用时，它们可以节省一天。您应该使用接口来解耦应用程序的两个组件或两个层。这可以使您轻松插入不同的接口实现而不会影响客户端，或者只是让客户端不受实现的持续更改，只要您坚持接口的合同即可。这可以使代码在长期内更易于维护，并且可以节省以后重构的工作量。

然而，过于激进的解耦可能导致非直观的代码。过度使用会导致滋扰。您应该仔细识别应用程序的内聚部分以及它们之间的界限，并在那里使用接口。在这些部件之间使用接口的另一个好处是它们可以并行开发，并使用他们使用的接口的模拟实现独立测试。

OTOH，让客户端代码直接访问公共成员方法是完全可以的，如果你真的没有预见到可能还需要对客户端进行更改的类的任何更改。但无论如何，我认为拥有公共成员领域并不好。这是非常紧密的耦合！您基本上暴露了类的体系结构，并使客户端代码依赖于它。明天，如果您意识到特定字段的其他数据结构将表现更好，则无法在不更改客户端代码的情况下进行更改。

Answer 6

我主要使用IoC接口来启用单元测试。

Answer 7

一方面，这可能被解释为过早概括。另一方面，使用接口作为规则可以帮助您编写更易于组合且因此可测试的代码。我认为后者在许多情况下胜出。

Answer 8

我喜欢接口：
*定义零件/模块/子系统或第三方系统之间的合同 *当存在可交换状态或算法（状态/策略）时

接口与公共类成员

8 个答案: