10

我目前正在做一些API设计工作，涉及到一些接口的规范作为抽象，稍后将由各种具体类实现。

碰巧，我使用的是 Java，但我认为这个问题与任何支持类似接口概念的语言有关。

我注意到通常有以下选择：

  • 用各种方法制作大界面
  • 制作多个接口，每个接口都包含全部方法的一个子集（单个具体类可能必须实现这些接口中的几个或全部）

每种方法的优缺点是什么？

4

7 回答 7

4

拆分接口的优点是您可以将方法划分为有意义的职责组。缺点是您的接口现在被拆分为一个类可能正在实现的一堆较小的接口。

我建议将界面拆分到有助于可读性的地方，仅此而已。如果您有一个实现 10 个接口的类，则这些接口需要合并为一个，或者可能该类承担了很多责任，它确实需要两个或更多类。

于 2011-01-21T14:34:05.787 回答
4

就反模式而言，我想说太多的接口可能会导致所谓的 Yo-yo-problem：

http://en.wikipedia.org/wiki/Yo-yo_problem

将所有内容放在一个接口中可能会创建 God 对象：

http://en.wikipedia.org/wiki/God_object

你应该在两者之间找到你的位置:)

祝你好运！

于 2011-01-21T14:40:23.647 回答
4

一个尚未提及的问题：将项目放入集合的接口应该与将项目取出的接口分开；组合接口应该从两者继承。以这种方式分离接口允许协变和逆变。例如，可以将 ReadableBunch(Of ToyotaPrius) 安全地传递给期望 ReadableBunch(Of Car) 的例程 [因为给出 ToyotaPrius 实例的对象将在这样做时给出 Car 实例] 和 WritableQueue(Of Car ) 可以安全地传递给期望 WriteableQueue(Of HondaCivic) 的例程 [因为可以接受 Car 的对象将根据定义接受 HondaCivic]。

我不知道这种类型的协变和逆变在 Java 中是否意味着什么，但由于这个问题被标记为与语言无关，任何为支持协变和逆变的平台（例如 .net）编码的人都应该考虑这个问题

于 2011-01-24T18:10:24.763 回答
2

我对你的问题没有很好的答案。API 设计是一门艺术。如果您正在进行一项大型设计工作，我建议您为自己获取一份NetBeans 名人 Jaroslav Tulach 撰写的Practical API Design的副本。

我认为他会建议反对太多的方法，其中一些可能只是辅助方法。您应该公开使用 API 所需的最低要求。越详细越好。

于 2011-01-21T15:39:51.793 回答
2

我不提倡使用太多方法的接口，因为我也不提倡类。必须使用此类接口或派生类的程序员将难以理解它们之间的关系；此外，试图记住它们是什么以及何时使用就像杂耍太多球一样。

对我来说，一般来说，一个模块超过 1000 行太多了；一个方法也有 100 多行；一个类或接口中也有超过 15 个方法。当然，也有例外，但我尽量避免。

在考虑哪些方法进入它们之前，我会定义你有哪些接口。考虑系统中每个抽象实体的“原子行为”是什么，并使每个实体成为接口，并在需要时使用继承组合。然后决定方法 - 在那之后，每个接口中可能不会有很多。

于 2011-01-21T14:33:03.523 回答
2

制作多个接口，每个接口都包含所有方法的一个子集

这种方法往往更适用于“优先组合而不是继承”的设计原则，因为单独的类每个都可以实现一个（或几个）接口。

于 2011-01-21T14:38:59.100 回答
2

接口中方法的数量应仅由其已知（或预期）用途决定。如果调用者通常使用接口的六个成员中的三个不同（但重叠）的成员，那么就是六个！

大量的方法通常表明内聚性差，而好的对象设计无论如何都应该对这个数字进行自然限制。但是你不应该仅仅为了减少它包含的方法的数量而拆分一个接口。

于 2011-01-21T15:56:27.300 回答