Java 获得正确的接口粒度级别

我目前正在做一些API设计工作，包括将许多接口规范为抽象，稍后将由各种具体类实现

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

我注意到，通常有两种选择：

• 使用全套方法制作大型界面
• 制作多个接口，每个接口包含全部方法的子集（单个具体类可能必须实现多个或所有这些接口）

---

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

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

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

---

我会先定义您拥有的接口，然后再考虑使用哪些方法。考虑系统中每个抽象实体的“原子行为”，并使每个实体成为一个接口，如果需要的话，用继承来构成。然后决定方法——在那之后，每个接口中可能不会有很多方法。

划分接口的好处是，您可以将方法划分为责任组，这些责任组在一起是有意义的。缺点是您的接口现在被分成了一堆较小的接口，一个类可能会实现这些接口

我建议将界面拆分为有助于可读性的部分，而无需进一步修改。如果您有一个类正在实现10个接口，那么要么这些接口需要组合成一个，要么这个类承担了很大的责任，实际上需要两个或更多的类

制作多个接口，每个接口包含全部方法的子集

---

这种方法在“”的设计原则下会更好地工作，因为单独的类可以每个实现一个（或几个）接口。

关于反模式，我认为过多的接口可能会导致所谓的Yo-Yo问题：

将所有东西放在一个界面中，可能会创建上帝对象：

你应该在两者之间找到自己的位置：）

---

祝你好运

我对你的问题没有好的答案。API设计是一门艺术。如果你正处于一个巨大的设计努力的中间，我建议你给自己一份NETBeaS名气的Jaroslav Tulach的拷贝。

---

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

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

---

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

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

---

我不知道这种协方差和逆变在Java中是否有任何意义，但由于这个问题被标记为语言不可知，任何为支持协方差和逆变的平台（例如.net）编码的人都应该考虑这个问题

你看过Bob Martin关于接口隔离原则的文章吗？@Nathan-非常有趣的文章-谢谢！@NathanHughes链接不再可用了。+1@Fabio你的数字很好。我会多拿一个经验法则数字。我避免函数使用超过4/5的参数。关于100行方法…实际上我的极限是s我的屏幕大小：如果我不能完整地阅读从开始到结束的所有函数，那么它太长了，所以我的限制是每个函数50行代码：-）我完全同意，包括方法大小-适合屏幕的大小是理想的。在我的具体情况下，我不得不稍微放宽这一规则，因为我想对我使用的所有语言使用相同的标准SE（java，c，C++，c++），当用C/C++编程时，Windows有时很难用小的方法来处理这些巨大的Win32 API函数和结构，它们看起来像IRS格式。好的原则-+1帮助我直接面对一个我正在进行的API设计决策。