1

我正在寻找不应使用接口隔离原则（来自 SOLID）的场景示例。

我看到的唯一提到（但未解释）的是 SOA 上下文中服务接口的情况。但为什么？是不是因为在这种情况下，界面设计上应该是胖的？通过 SOA 法令？

是否还有其他情况表明 ISP 不是一个好主意？

提前致谢。

4

3 回答 3

1

SOLID 是很好的原则，我的想法是，当您认为自己过度设计时，您不应该应用它们！例如，我主要在我的服务层的类上应用 ISP，在业务层，我将更改我的类，因为它是业务的变化，我不会创建新的实现（并且我打破了打开/关闭原则，但我不在乎，因为这是业务变化！）。

编辑：我还在我的数据层中应用了 ISP，所以事实上我主要将 ISP 应用于所有 I/O 事务（xml、sql、电子邮件......）。

如果你在任何地方都应用 ISP，你最终会得到数百个接口，这可能是调试/初始化的噩梦。

于 2011-12-08T08:24:22.163 回答
0

不应用 ISP 的好时机是当您开始使用小型接口并且随着时间的推移您了解更多有关该域并发现它们中的一些是耦合的时。那些耦合的可以重构为更少的接口，因为您可以从现实世界的用法（三规则）中看到它们属于一起——它们的行为是相关的；它们在相同的上下文和场景中使用。正是有了相关接口的这种经验，才能做出明智的决定来折叠它们。然后你的域变得更丰富，你不会 太早干。

上述建议的问题在于，您实际上是从小开始应用 ISP，然后再转向大。也许这个问题没有实际意义？:p

于 2016-12-22T14:43:09.150 回答
-3

如果我没有超过 1 个实现，我不会使用接口。到时候我就应用这个原则。关于接口的整个想法是有多个实现。祝你好运。

于 2011-12-07T17:03:07.210 回答