问题标签 [interface-segregation-principle]

SOLID 的接口隔离原则说类不应该实现/依赖于它们不需要的方法。你永远不应该 //Not used: just needed to implement interface在代码库中。

当某些方法本质上是“可选的”时，我该如何应用这个原则，因为实现类是一个特定的极端情况。

假设我有这个接口示例：

该接口在程序中被其他类广泛使用。目前在我的程序中，我正在做类似以下的事情。

它被 C 类调用；

我应该如何更改设计以符合 ISP，而不更改 C 类，同时也不需要检查对象是否instance of在运行时？

我在 java 8 中模拟公共接口时遇到问题。我现在有这个方法的接口：

接口 A 由 class 实现B，它是一个抽象类：

method1包含所有逻辑，应该是开发人员可以看到/使用的逻辑。

现在，下面表示类的具体表示B：

因此，总而言之，B 的具体实现实现了method2（和方法3，如果用户愿意）。B 类实现了method1，其中包含所有逻辑。

我的问题是，当我这样做时ConcreteB.getInstance()，开发人员可以使用的方法是method1、method2和method3，并且我只想让开发人员可以看到 method1。但是因为 java 8 不允许我在接口上创建私有方法，所以我不知道该怎么做。

有关如何解决此问题的任何提示？

谢谢！

我在这里阅读了 Robert Martin 关于接口隔离原则的文章。在文章的最后，在解决 ATM UI 架构的问题时，他说：

还要考虑 ATM 可以执行的每个不同事务都被封装为 Transaction 类的派生类。因此，我们可能有诸如DepositTransaction、WithdrawlTransaction、TransferTransaction等类。这些对象中的每一个都向UI. 例如，DepositTransaction对象调用类的RequestDepositAmount成员函数UI。而TransferTransaction对象调用的RequestTransferAmount成员函数UI。这对应于图 5 中的图表。

请注意，这正是 ISP 告诉我们要避免的情况。每个事务都使用UI其他对象不使用的一部分。这产生了对 的一个派生的Transaction更改将强制对 的相应更改UI，从而影响 Transaction 的所有其他派生以及依赖于UI接口的所有其他类的可能性。

所以我们有以下情况：如果Transaction' 的派生之一被改变，UI则被改变并且任何其他使用的类也UI被改变。

然后通过以下更改解决了该问题：

这种不幸的耦合可以通过将 UI 界面分离成单独的抽象基类来避免，例如DepositUI, WithdrawUI和TransferUI. 然后可以将这些抽象基类多次继承到最终的UI抽象类中。图 6 和清单 6 显示了这个模型。

但接下来罗伯特·马丁说：

确实，每当创建 Transaction 类的新派生时，都需要抽象 UI 类的对应基类。因此，UI 类及其所有派生类都必须更改。然而，这些类并没有被广泛使用。实际上，它们可能仅由 main 或任何启动系统并创建具体 UI 实例的进程使用。因此，添加新 UI 基类的影响是可控的。

这就是问题：它怎么可能UI改变了，但其他类也没有改变？毕竟，如果某种TransactionX使用XUIandXUI是 and 的超类UI并且UI被更改（因为 some ZUI），那么（就我而言）编译器也需要重新编译所有使用的类XUI，因为 vtable（就 C++ 而言）或者可能某些函数基地址已因UI. 有人可以帮我弄干净吗？

我是 JUnit 的新手。我尝试编写一个简单的服务类“ProductService”的单元测试。这是我的“ProductService”测试代码

如您所见，有些函数可能会引发错误。此外，其他功能测试简单的“CRUD”操作。我应该将可能向另一个接口抛出错误的函数分开吗？如果我将它们分开，我可以提供接口隔离吗？谢谢你的帮助。

假设我有一个接口：

问题是方法doSpecificAction1和方法doSpecificAction2是可选的，并非所有工作人员都支持。Worker 可以同时支持doCommonAction1and doCommonAction2only 以及doCommonAction1, doCommonAction2and doSpecificAction1, or doCommonAction1, doCommonAction2, doSpecificAction2, 或所有方法。

我还有一个 WorkerFactory：

然后我有一个控制器：

很明显，现在我的代码违反了接口隔离原则。我想重构它。好的，我尝试做这样的事情：

所以现在我的工人看起来像这样：

现在我的控制器更改为：

但我认为这段代码看起来很难看。我不确定使用 instanceof 是一个好主意，尤其是因为SpecificAction1AwareInterface根本SpecificAction2AwareInterface不相关WorkerInterface。

那么有没有适合我情况的设计模式呢？先感谢您。

我对装饰器模式有一些疑问。据我了解，装饰器模式的存在是为了向对象添加行为，即“装饰对象”，因此您可以组合不同的对象，而无需实现大量不同的类，只需进行微小的更改，从而导致“类爆炸” ”。

现在的问题是，一般化的装饰器模式说我们应该有一个基类，然后我们的装饰器类扩展它，但也可以从中进行委托。所以装饰器本质上“是一个”和“有一个”基类（以及它的方法）。

问题就来了，因为让我们说我想为一个游戏组成一个“玩家”，实际上有很多不同的玩家，而且都有微小的变化。然后我可能想使用装饰器模式（？）并说“好吧，我们的基类是普通人”。我想用枪和防弹衣装饰这个人。然后我的装饰器类 gun 将实现与人类相同的方法，让我们说“吃”。但是我的枪肯定不会吃，我只希望它能够射击。我可以通过返回 null 或其他东西来解决这个问题，但这也会破坏接口隔离原则。

那么我如何在不破坏 ISP 的情况下解决这个问题，同时又不需要创建大量更改最小的类，例如“带枪的人”、“带枪和防弹衣的人”、“带工作人员和防弹衣的人”， “人与员工”，你明白了。

我的目标是理解接口隔离原理，同时实现多态。

我的预期结果：我可以通过接口隔离原则实现多态性。

我的实际结果：不，我不能。我被迫创建样板并使用 Liskov 替换原则（如果有 Worker，则必须有一个不能吃的 Worker，所以为 Worker 创建一个可以吃的接口，扩展 Worker）。我想我误解了接口隔离原则。

这是违反接口隔离原则的代码。

我被告知将接口分成2。

解决方案是使用 Liskov 替换原则。

我有以下接口：

并且有一个管理器类，它提供一个列表来存储端点，以及一个从该列表中获取端点的方法。这就是我迄今为止为该方法所做的：

但是我们都知道这是怎么回事，意大利面条代码......所以，我的问题是：找到并返回该端点的最佳方法是什么？

在这个问题中，作者给出了为什么将default关键字引入 java 语言的一些原因。提供的原因之一是支持可选方法。

但是，考虑到ISP，不应强迫任何客户端依赖它不使用的方法。

（来自维基百科）在软件工程领域，接口隔离原则 (ISP) 指出不应强迫任何客户端依赖它不使用的方法。 [1] ISP 将非常大的接口拆分为更小、更具体的接口，以便客户端只需了解他们感兴趣的方法。这种缩小的接口也称为角色接口。

从我的角度来看，我们应该鼓励我们将函数拆分为小接口，而不是按照默认技巧将所有内容都放在单个接口中。

让我们想象一下，我们有一个大型数据结构（我们称之为Configuration）和各种客户端类（我们称之为它们Services）。每个服务只需要一个或两个字段Configuration。

如果我们将整个Configuration对象注入到各个Services中，这是否违反了ISP？Configuration技术上是数据结构而不是字面 Java 接口这一事实是否改变了 ISP 背后的基本点？

我面临的实际困境是如何配置对我的系统的各个部分可用。我可以选择使用 Spring 的@Value注解，通过它每个组件都能准确地获得它需要的东西，仅此而已。我的第二个选择是使一个Configuration实例作为一个整体可用。在第二种情况下，系统的每个组件都将获得整个系统的配置，而不是只获得它实际需要的几个部分。

我试图了解第二种选择是否违反 ISP。