问题标签 [interface-segregation-principle]

SOLID “接口隔离原则”与“单一职责原则”有何不同？

SOLID的维基百科条目说

ISP 将非常大的接口拆分为更小、更具体的接口，以便客户端只需了解他们感兴趣的方法

然而，对我来说，这听起来就像只是将 SRP 应用于接口和类。毕竟，如果一个接口只负责一个概念上的事情，那么您将无法进一步分解它。

我错过了什么，还是 ISP 与 SRP 有点多余？如果不是，那么 ISP 暗示 SRP 没有什么？

从具有未使用方法的类继承是否违反了接口隔离原则？

例如：

Concrete取决于 method Base.Receive(int n)，但它从不使用它。

UPD

我使用的定义：

ISP 声明不应强迫任何客户端依赖它不使用的方法。

To remind (from wiki):

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

And now look at my example.

Here's my mutable entity. It is edited from somewhere and it is able to notify about changes through read-only interface:

And here's the class from transport layer which uses it. Look at two variants of injection (Attach_1 and Attach_2) and my assumptions below:

1. ISP is about real objects. You must not use "excessive" references to incoming parameters.
2. ISP is about classes. If your class already uses full interface somewhere, no need to restrict reference type in particular methods. ICounter interface is excessive in this example.
3. This architecture is completely wrong from the point of SOLID principles (then why?).

java.awt.event 包中适配器模式的使用让我感到困惑。一方面，这似乎明显违反了接口隔离原则 (ISP)。

与 MouseMotionAdapter 类实现 MouseMotionListener 类似，但为这两种重写方法提供“NIL”实现。

这正是 ISP 违规的全部内容？通过 ISP，MouseMotionListener 会被分成两个独立的接口，一个用于 moseDragged 和 moveMoved 行为？

也许以这种方式拆分接口会增加接口的数量，并且还会使编码更加不优雅，因为每个实现类都需要实现大量接口。

如果我的论点是合理的，只需要澄清一下吗？

我对编程相当陌生，我很难理解如何有效地应用以下链接（ATM 链接）中显示的原则：

http://www.objectmentor.com/resources/articles/isp.pdf

基本上，它从不抱怨 ISP（接口隔离原则）的设计开始，然后继续将行为重构为不同的接口。

我的问题是：我们不使用接口来表达不那么（或不）相关的抽象之间的共同行为吗？

将方法封装在接口中的意义何在，即使没有一个方法与将要实现它们的类共享？在哪种情况下这可能被认为是有用的？

如果我们继续该示例的行，则给出以下代码：

据我了解，为了使用以前的设计，我们应该有类似的东西：

现在，我们不需要 IMPLEMENTATIONUI 实现每一个方法吗？如果是这样，它不会破坏 SRP 吗？

不止一次，我发现自己在使用一个封闭的类（我无法修改它），我希望实现一个适合我需要的窄接口。我的客户端代码应该拥有该接口，但我不知道有任何机制可以宣布这个封闭类是我的缩小接口的实现。

我试图让这个类被传递（依赖注入）到我的代码（组合）中，但也允许其他任何可以支持窄接口的东西。在其他语言中，鸭子打字使这变得微不足道。虽然我在java中，所以我希望必须编写一个完整的其他类来包装封闭类以实现这一点。有没有我想念的方法？

谢谢

编辑以解决欺骗：

接口隔离原则没有提到封闭类问题，这是这个问题的重点。请重新考虑标记为这个特定问题的欺骗。

这个问题： Interface Segregation Principle-Program to an interface，有一个很好的接口隔离原则示例：

会变成

但请注意它如何需要对 A 类进行更改。如果 A 对修改关闭，我如何干净地完成同样的事情？

这种情况发生在我身上很多次，我不知道如何解决它。

接口隔离原则是为了防止出现某些接口实现不使用它的功能的情况——这是显而易见的。经常有这样的情况，我有一个接口列表，我想用它们做点什么。让我们看一个没有 ISP 的例子：

我想和每个人一起跑步。

现在我想和他们一起吃饭。

现在，如果我想使用 ISP，我应该将代码更改为：

我应该如何列出我的人员名单？我应该制作两个 Runable 和 Eatable 列表并添加对象（丑陋）还是第二种方法 - 创建一个列表并在可能的情况下投射它们（丑陋）？我不知道这样做的最佳惯例是什么。

这个例子可能不是我能想象的最好的例子，但我希望你明白我的意思。

已编辑：我更改了接口和类以及原理名称。

今天在一次采访中被问到什么是接口隔离原则，与此相反的情况或原则是什么。

ISP对我来说很清楚，但我不知道问题的第二部分，与ISP相反的原理是什么？

我不明白接口隔离原则和开放/封闭原则之间有什么区别。

我的理解是，ISP 必须使一切都依赖于接口和类上的 OCP，我看到它们都可以以相同的方式实现，但一种是接口，另一种是类。

我正在尝试遵循接口隔离和单一职责原则，但是我对如何将它们组合在一起感到困惑。

在这里，我有几个接口的示例，我将其拆分为更小、更定向的接口：

我稍微简化了它（有些where条款妨碍了可读性）。

目前我正在使用SQLite ，但是，这种模式的美妙之处在于，如果我选择不同的数据存储方法（例如Azure），它有望让我有机会更好地适应变化。

现在，我对每个接口都有一个实现，下面是每个接口的简化示例：

现在，我在将它们整合在一起时遇到了问题，我确定总体思路是创建一个Database使用接口而不是类（真正的实现）的类。所以，我想出了这样的事情：

这里的问题是我应该如何向客户端公开IDataRead、IDataWrite和IDataDelete接口？我应该重写重定向到接口的方法吗？像这样：

突出显示我的评论，这看起来有点愚蠢，我费了很多力气将这些类分成很好的、分离的实现，现在我将它们全部重新组合到一个大类中。

我可以将接口公开为属性，如下所示：

这感觉好一点，但是，不应该期望客户端必须经历决定他们需要使用哪个接口的麻烦。

我完全错过了这里的重点吗？帮助！