程序员很容易发现spot肿的界面，并且通常会随身携带各种各样的“刀和刺伤武器”，以应对这种情况。 先前的文章介绍了界面效率方程式，并演示了由该方程式推动的算法，以指导这一屠宰活动。
但是，发现一个棘手的问题是，将一个接口家族的成员切得太小，以至于熟练的重新组合可能会带来设计上的好处。
换句话说，如果一组小的接口自发地合并为一个大接口，而程序员不得不拆分那个大接口，那么会出现同样的小接口吗？ 如果它们这样做，那么那些小型接口将保留其独立性的主张。 如果它们不这样做，则可能表明接口过度隔离，并且这些接口之间的行为分配不当。
让我们看一下最近审查过的程序Apache Lucene ，以了解当将其接口视为相关集合时，接口的分离是多么成功。 在这里，我们将假定同一包中的接口是“相关的”。
图1显示了Lucene的org.apache.lucene.search.spans包中的6个接口，它们总共包含25种方法（此分析在接口和抽象类之间没有区别）。
图1：Lucene的spans包中的接口。
我们将所有这些方法收集到一个接口中，并完全基于客观接口效率计算来分解该接口。
（回想一下，如果类A是接口I的客户端，并且我有10个方法，其中A调用10，则I相对于A效率为100％。如果A仅使用其中3个方法，则I仅为30％如果第二类B使用6种方法，则我的效率是两个客户的平均值=（30％+ 60％）/ 2 = 45％。）
图2显示了使用先前文章中介绍的算法在新近隔离的接口之间对方法进行的假设重新分配。
图2：重新想象了Lucene的spans包接口。
图2中重新分配的接口在很大程度上保留了它们的完整性，只有一个消失了。 最大的影响是将接口ConjunctionSpans和Spans合并到接口2中 ，这表明客户端可以同时使用这两个接口，但是如图1所示，分离这些接口似乎没有什么错误，因此这些接口证明了它们当前的配置合理。
但是，如果我们看一下另一个Lucene软件包，则会看到一个不同的故事。 软件包org.apache.lucene.analysis.tokenattributes包含23种方法的9个接口，见图3。
图3：Lucene的tokenattributes包中的接口。
如果将图3的接口组合在一起，然后使用我们的算法将这个大接口拆分为一个有效的集合，我们得出图4。
图4：重新想象的Lucene的token-attributes包接口。
图4将集合从9个减少到只有4个。 接口1主要包含CharTermAttribute接口和少量添加项，而接口3是两个小型接口的组合。 但是，接口2已将4个整个接口合并为一个接口，这表明-从效率的角度来看-接口集合值得进一步研究。
当然，程序员将接口隔离的原因不仅仅是接口效率，原因还可能在于：较小的接口反映了可以以各种形式组合的不同实现，或者它们的语义独特性证明了这种分离是合理的。
而且，这仅仅是静态代码分析，而静态分析从不回答设计问题：它们只是提出问题。 但是，这里提出的问题很清楚：是什么促使当前代码库中接口2的方法分裂？
摘要
接口隔离原则建议不要将大型接口拆分为较小的接口，而应将大型无效接口拆分为较小的有效接口。 如果所有二十个客户端类都调用一个接口的所有六十种方法（在现代软件系统中，这确实是很少见的），那么该接口的设计很好，不应该分解。
小型接口是一种实用的折衷方案，但最大的目标是大型接口。
过度隔离的接口可能会导致接口片段对云产生更多的影响，而不是澄清设计意图。
翻译自: https://www.javacodegeeks.com/2015/08/interface-over-segregation.html