获得正确的接口粒度级别
我目前正在做一些API设计工作，涉及将许多接口规范为抽象，稍后将由各种具体类实现。
碰巧，我使用的是 Java，但我认为这个问题与任何支持类似接口概念的语言相关。
我注意到，通常有一个选择：
- 制作一个具有全套方法的大型接口
- 制作多个接口，每个接口包含全部方法的子集（单个具体类可能必须实现其中的几个或全部）接口）
每种方法的优点/缺点是什么？
I'm doing some API design work at present, involving the specification of a number of interfaces as abstractions that will later be implemented by various concrete classes.
As it happens, I am using Java, but I think the question is relevant to any language that supports a similar interface concept.
I've noticed that there is often an option between:
- Making a large interface with a full range of methods
- Making multiple interfaces each containing a subset of the full range of methods (a single concrete class would probably have to implement several or all of these interfaces)
What are the pros / cons of each approach?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
拆分接口的优点是，您可以将方法划分为多个职责组，这些职责组合在一起才有意义。缺点是您的接口现在被分成一堆较小的接口，一个类可能会实现这些接口。
我建议将界面拆分为有助于可读性的部分，而不是进一步拆分。如果您有一个类实现 10 个接口，那么要么需要将这些接口合并为一个，要么该类可能承担了很多责任，并且它确实需要是两个或更多类。
The pro of splitting out the interface is that you can divide the methods into groups of responsibilities that make sense to be together. The con is the your interface is now split into a bunch of smaller ones that one class might be implementing.
I would recommend splitting the interface out where it helps readability and no further. If you have one class that is implementing 10 interfaces, either those interfaces need to be combined into one, or possibly the class is taking to much responsibility and it really needs to be two or more classes.
就反模式而言，我想说太多的接口可能会导致所谓的 Yo-yo-problem：
http://en.wikipedia.org/wiki/Yo-yo_problem
将所有内容放在一个界面中可能会创建上帝对象：
http://en.wikipedia.org/wiki/God_object
您应该在两者之间找到自己的位置:)
祝您好运！
In terms of anti-patterns I would say that too much interfaces may lead to the so called Yo-yo-problem:
http://en.wikipedia.org/wiki/Yo-yo_problem
And putting everything in a single interface may create the God object:
http://en.wikipedia.org/wiki/God_object
You should find your place somewhere in between :)
Good luck!
有一个问题还没有提到：将项目放入集合的接口应该与取出项目的接口分开；组合接口应该继承两者。以这种方式隔离接口可以实现协变和逆变。例如，一个 ReadableBunch(Of ToyotaPrius) 可以安全地传递给一个期望 ReadableBunch(Of Car) 的例程 [因为给出 ToyotaPrius 实例的对象将给出 Car 的实例] 和一个 WritableQueue(Of Car) ) 可以安全地传递到需要 WriteableQueue(Of HondaCivic) 的例程 [因为可以接受 Car 的对象根据定义将接受 HondaCivic]。
我不知道这种类型的协变和逆变在 Java 中是否意味着什么，但由于这个问题被标记为与语言无关，因此任何为支持协变和逆变的平台（例如 .net）编码的人都应该考虑这个问题
One issue not mentioned yet: interfaces which put items into a collection should be separate from those which take items out; a combined interface should inherit from both. Segregating interfaces in this way allows for covariance and contravariance. For example, a ReadableBunch(Of ToyotaPrius) may be safely passed to a routine expecting a ReadableBunch(Of Car) [since an object that gives out instances of ToyotaPrius will in so doing give out instances of Car] , and a WritableQueue(Of Car) may be safely passed to a routine expecting a WriteableQueue(Of HondaCivic) [since an object that can accept a Car will by definition accept a HondaCivic].
I don't know if this type of covariance and contravariance mean anything in Java, but since the question was tagged language-agnostic, the issue should be considered by anyone coding for platforms that support covariance and contravariance (e.g. .net)
该方法往往更适合“
That approach would tend to work better with the design principle of "prefer composition to inheritence", because separate classes could each implement one (or a few) of the interfaces.
我对你的问题没有一个好的答案。 API 设计是一门艺术。如果您正在进行大型设计工作，我建议您获取一份实用 API 设计 由 NetBeans 成名的 Jaroslav Tulach 撰写。
我认为他会建议不要使用太多方法，其中一些可能只是辅助方法。您应该公开使用 API 所需的最低限度。越少冗长越好。
I don't have a nice answer to your question. API design is a bit of an art. If you are in the middle of a large design effort, I recommend you get yourself a copy of Practical API Design by Jaroslav Tulach of NetBeans fame.
I think he would recommend against too many methods, some of which might just be helper methods. You should expose the minimum needed to work with the API. The less verbose, the better.
我不会提倡使用太多方法的接口，就像我也不会提倡使用类一样。必须使用此类接口或派生类的程序员将很难理解它们之间的关系；此外，试图记住它们是什么以及何时使用就像玩弄太多的球一样。
对我来说，一般来说，一个模块超过 1000 行就太多了；一个方法中的行数也超过 100 行；类或接口中也有超过 15 个方法。当然，可能会有例外，但我会尽力避免它们。
在考虑使用哪些方法之前，我会先定义您拥有哪些接口。考虑系统中每个抽象实体的“原子行为”是什么，并使每个实体成为一个接口，如果需要的话可以与继承组合。然后决定方法——之后每个接口可能就不会很多了。
I wouldn't advocate for an interface with too much methods, as I wouldn't for a class as well. The programmer that have to use such interfaces or the derived classes would have trouble understanding how they relate; furthermore trying to remember what they are and when to use is like juggling too many balls.
To me, in general, more than 1000 lines in a module is too much; more than 100 lines in a method too; more than 15 methods or so in a class or interface, too. There can be exceptions, of course, but I try to avoid them.
I'd define which interfaces you have before thinking which methods go into them. Consider what are the 'atomic behaviors' for each abstract entity in your system and make each entity an interface, composing with inheritance if needed. Then decide the methods - after that, probably there wouldn't be many in each interface.
接口中方法的数量应仅由其已知（或预期）用法驱动。如果调用者通常使用接口的六个成员中的三个不同（但重叠）的成员，那么就是六个！
大量的方法通常表明内聚性较差，无论如何，良好的对象设计应该对该数量施加自然限制。但是您不应该仅仅为了减少接口包含的方法数量而拆分接口。
The number of methods in an interface should be driven only by its known (or expected) usage. If callers typically use three different (but overlapping) members of an interface's six members, then six it is!
A large number of methods often indicates poor cohesion and good object design should place a natural limit on that number anyway. But you shouldn't ever split an interface just to reduce the number of methods it contains.