接口隔离原则何时不适用？ SOA？

Question

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

我所见过的唯一一个（但未解释）是SOA上下文中服务接口的情况。但为什么？是因为在这种情况下接口应该是设计的胖吗？通过SOA法令？

还有其他情况下ISP不是个好主意吗？

提前致谢。

Answer 1

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

编辑：我也在我的数据层中应用ISP，所以我实际上我主要为所有I / O事务（xml，sql，email ...）应用ISP。

如果您在每个地方都应用ISP，那么最终会有数百个接口，这可能是调试/初始化的噩梦。

Answer 2

不使用ISP的好时机是，当您开始使用小型界面时，随着时间的推移，您会了解有关该域的更多信息，并发现其中一些是耦合的。那些耦合的可以重构为更少的接口，因为你可以从现实世界中看到它们（Rule Of Three）它们属于一起 - 它们的行为是相关的;它们用于相同的上下文和场景中。通过相关界面的这种经验，可以做出明智的决定来解决它们。然后，您的域名变得更加丰富，而您又not being DRY too early。

上述建议的问题在于，实际上是在应用ISP ，从小开始，然后转移到大。也许这个问题没有实际意义？ ：P

Answer 3

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