关于java：接口隔离原理背后的原因是什么？

接口隔离原理(ISP)说，许多客户端特定的接口比一个通用接口要好。 为什么这很重要？

ISP指出：

Clients should not be forced to depend
on methods that they do not use.

ISP与重要特性-内聚力和耦合力有关。
理想情况下，您的组件必须高度定制。它提高了代码的健壮性和可维护性。

实施ISP可为您带来以下好处：

• 高内聚性-更好的易懂性，鲁棒性
• 低耦合-更好的可维护性，高抗变化性

如果您想了解有关软件设计原理的更多信息，请获取一份副本
敏捷软件开发，原理，模式和实践一书。

界面隔离是SOLID原则上的" I"，在深入探讨前者之前，让我们解释一下后者的含义。

SOLID可以被视为专家提出的一组最佳实践和建议(这意味着它们已被证明)，以便为我们设计应用程序的方式提供可靠的基础。这些实践努力使维护，扩展，适应和扩展我们的应用程序变得更加容易。

我为什么要关心SOLID编程？

首先，您必须意识到自己永远不会永远存在。如果我们使用标准和众所周知的体系结构，则可以确保我们的代码将易于跟随我们的其他开发人员进行维护，并且我确定您将不想处理修复未完成的代码的任务。没有应用任何已知的方法，因为很难理解它。

接口隔离原则。

知道我们知道SOLID原理是什么，我们可以更详细地了解接口隔离原理，但是接口隔离究竟说明了什么？

"Clients should not be forced to implement unnecessary methods which
they will not use"

这意味着有时我们倾向于使用很多方法来建立接口，这些方法在一定程度上可能是好的，但是很容易被滥用，并且我们最终会得到实现空方法或无用方法的类，这当然会增加额外的代码和负担。到我们的应用程序。
假设您在单个接口中声明了许多方法，如果您喜欢可视化辅助工具，则该类正在实现接口，但实际上确实需要使用其中的几个方法，如下所示：

另一方面，如果您正确地应用接口隔离并将接口拆分为较小的子集，则可以确保实现仅需要的子集：

看到！更好！加强该原理将使您具有较低的耦合，从而有助于更好的可维护性和较高的抗更改性。因此，您可以在需要时真正利用接口的用法并实现方法。
现在，让我们回顾一个不太抽象的示例，假设您声明了一个名为Reportable的接口

并且您有一个仅以Excel格式导出某些数据的客户端，您可以实现该接口，但是您是否仅需要实现excel方法？答案是否定的，即使您不打算使用所有方法，也必须对所有方法的实现进行编码，这可能会导致大量垃圾代码，从而使代码难以维护。

记住要保持简单，不要重复自己，您会发现自己已经在不知不觉中使用了这一原理。

它简化了任何一个客户端将使用的界面，并删除了它们可能会在不需要的界面部分上开发的依赖关系。

该原则主要用于双重目的

• 使代码更具可读性和可管理性。

• 促进班级的单一责任感(高度凝聚力)。当然，为什么一个类应该有一个没有行为影响的方法？为什么不删除它呢？多数民众赞成在什么是关于

设计师必须向ISP提出的几个问题

• ISP可以实现什么
• 如何分析任何ISP违规的现有代码

为了使讨论更深入，我还必须补充一点，从最严格的意义上讲，该原理并不是"原则"，因为在某些情况下，将ISP应用于设计而不是提高可读性可能会使对象结构不可读且混乱。不必要的代码。
您可能会在java.awt.event包中观察到这一点

有关更多信息，请访问我的博客：http://design-principle-pattern.blogspot.in/2013/12/interface-segregation-principle.html

一个原因是，拥有许多接口且每个接口使用最少的方法，可以更轻松地实现每个接口并正确实现它们。较大的界面可能不规则。同样，在方案中使用重点界面使代码更具可维护性，因为您可以看到正在使用对象的哪个方面(例如，IComparable接口可让您知道对象仅在给定方案中用于比较)。

ISP很重要。

ISP的基本思想：不应强迫客户端依赖于不使用的方法。

这个原则似乎更合乎逻辑。理想情况下，客户端不应实现客户端不使用的方法。

有关代码示例，请参见下面的SE问题：

接口隔离原理-编程接口

好处：

罗伯特·马丁(Robert Martin)关于该主题的论文给出的解释很少被提及：

The backwards force applied by clients upon interfaces.

如果两个类直接依赖于第三类的两种不同方法，则前两个类中任何一个的更改都会影响另一个类。

假设我们有三个类：Red，Green和Blue。

Red和Green都依赖Blue，但是都依赖于不同的方法。这意味着Red依赖于Blue的一种方法，但不使用另一种方法。同样，Green依赖于Blue，但仅使用一种方法，而不使用另一种方法。

在Red和Green中违反了该原理，因为每个都依赖于一个类-Blue-但没有至少使用其方法之一。

这可能会导致什么问题？

• 我需要更改Red，并且还更改Blue以适应Red的需求。
• 我没有更改Green所依赖的Blue中的特定方法，但是，Green依赖于Blue，并且我已经更改了Blue，这仍然可能影响Green。
• 因此，我对Red所做的更改有可能影响Blue，因为它们使我更改了两者都依赖的类。

那就是"向后的力量"。我们有时会根据客户的需求更改班级。如果该类有不同的客户将其用于不同的事物，则我们有可能影响他们。

如前所述，接口隔离原理的简单定义是：

no client should be forced to depend on methods it does not use.

在此与罗伯特·马丁(Robert Martin)论文的上述观点之间，很明显，对ISP的许多解释实际上是在谈论其他原理。

• 具有许多方法的类或接口是不可取的，但不是特别由于ISP的原因。他们可能违反单一责任。但是，违反ISP的不是大型接口或大型类，而是在不使用大型接口的所有方法的情况下，它们依赖于大型接口。如果他们使用所有方法，听起来还是很混乱，但这与ISP无关。
• 实现一个接口但为某些方法引发异常的类是不好的，但这也不是ISP。 ISP是关于依赖于接口的类，而不是实现接口的类。

如果我们使用Google进行"接口隔离"，则大多数包含代码示例的顶级结果都表明了无法完全实现接口的类，而这并不是ISP的重点。有些人甚至重申了这一原则：

The Interface Segregation Principle states that clients should not be forced to implement interfaces they don't use

...但这不是原则。定义文件将此类担忧视为违反ISP的副作用，但指出它们是违反Liskov换人条款的行为。

Moreover, each time a new interface is added to the base class, that interface must be
implemented (or allowed to default) in derived classes. Indeed, an associated practice is to add these interfaces to the base class as nil virtual functions rather than pure virtual functions; specifically so that derived classes are not burdened with the need to implement them. As we learned in the second article of this column, such a practice violates the Liskov Substitution Principle (LSP), leading to maintenance and reusability problems.

而且，说一个客户不应该实现它不使用的方法甚至没有道理。接口的客户端未实现其方法。

我的意思不是要夸张引用这篇论文，好像它是圣旨或其他东西一样。但是，如果我们要使用文章中描述的原理的名称(文章本身的名称)，那么我们还应该考虑该文章中包含的实际定义和解释。