接口中的方法数

Question

我知道这似乎是一个有争议的问题，但实际上并非如此。 在接口中是否有最佳方法数。

例如，我个人讨厌使用20种方法的界面。这很难实施。合同似乎难以维持。 同样，如果方法的数量只是1.这让我想知道它是否真的是一个很好的抽象。

有什么想法？

Answer 1

接口应该具有所需数量的方法。例子：

java.lang.Iterable - 1方法
java.lang.Comparable - 1方法
java.util.Collection - 14种方法
java.util.List - 25种方法（包括来自Collection的方法）

所以答案是 - 不要将数字作为界面的标准。相反，将方法放在逻辑上属于它们的接口中。

Answer 2

有一个well-known study表明我们一次可以处理的信息项数是7，加减2。我经常发现这对于这类问题是一个很好的经验法则 - 在这种情况下，如果界面设计为管理一组相关的功能，我们可能无法将功能理解为单一设置是否超过七个。

但是，对于许多接口，开发人员不需要能够将功能理解为单个相关集，在这种情况下，此规则将不相关。

Answer 3

使用一种方法的良好接口通常有其用途，您可以更容易地匿名实现它们。我的经验法则是尽可能多的方法。但是，一个界面中的许多方法通常表明您可以将其拆分为多个其他界面，尤其是当它影响不同的任务区域时（例如，UserLoginAndAdministrationInterface变为一个UserLogin和一个UserAdministration界面）。您可以在类中实现任意数量的接口，也可以将它们子类化。因此，拆分它们并不会造成任何伤害。

Answer 4

接口应该具有与需要一样多的方法。

如果该数字很大，则应仔细查看基本原理，但可能有效。

另一方面，Java中存在（至少）一个实例，其中接口不需要方法（可序列化），因此没有。更少的方法，肯定使得实现界面更容易，但仍然可以提供非常有用的抽象。有一种方法有许多接口。

Answer 5

我更关心的是，界面在逻辑上是一致的，而不是具有一些任意最佳方法。也就是说，大量的方法可能表明一个应该重构的“上帝”对象。更明确的指示是方法不具有凝聚力，但方法的数量可能更容易观察并引导您进行更仔细的检查。但有时候，你只需要有很多方法，因为你想对这种类型的对象做很多可能的操作。这方面的一个例子就像.NET中的IEnumerable<T>。我想不出将这些分解为单独接口的任何正当理由，但接口中有很多方法。

Answer 6

接口中有 no 最佳方法数。接口用于各种不同的东西，什么是合适的取决于什么。

在一个极端情况下，一个接口可能会被一个程序自动代码生成，供另一个程序使用，并且有充分的理由可能有1000个方法。

对于人类可读的代码，规则不能代替判断。

Answer 7

7 ± 2

Answer 8

对于接口可以接受的方法，没有正确或错误的答案。有些可以有零，有些可以有，有可能很少有超过一百。我写过的最大的界面是近三十种方法，但它是客户的外观。

但是我认为一个接口超过8-10种方法可能会导致代码冒烟 - 只需要5秒就可以进行调查。

Answer 9

当您只需要实现一些方法时，处理许多方法的方法是提供默认实现的Abstract类或throw NotImplementedException。如果只有一种方法，那么它可能是正常的，因为有些方法只期望一个Iterface并调用一个方法。有许多模式，例如Vistor只需要一种方法。

Answer 10

这20种方法要么捕捉到有用的东西，要么不捕捉。如果他们这样做，那么您需要实施所有来为他们捕获的内容提供实现。在这种情况下，将它们放在同一个界面中是一致的。

Answer 11

答案是 - 不要将数字作为界面的标准。相反，将方法放在逻辑上属于它们的接口中，您可以在不同的类中使用它 你可以在两个或多个类中使用一种接口方法，所以不要犹豫，使用它是一个很好的编程技术接口。