接口隔离原理的两个矛盾定义–哪个正确？

在阅读有关ISP的文章时，似乎对ISP有两个相互矛盾的定义：

根据第一定义（见1，2，3），ISP指出，实现该接口的类不应该被迫实施的功能，他们并不需要。因此，胖界面IFat

interface IFat
{
     void A();
     void B();
     void C();
     void D();
}

class MyClass: IFat
{ ... }

应该分成较小的接口，ISmall_1并且ISmall_2

interface ISmall_1
{
     void A();
     void B();
}

interface ISmall_2
{
     void C();
     void D();
}

class MyClass:ISmall_2
{ ... }

因为这样我MyClass能够实现只需要（方法D()和C()），而无需被迫还提供了虚拟实现A()，B()并且C()：

但根据第二个定义（见1， 2，通过纳扎尔Merza答案），ISP指出MyClient调用方法MyService不应该知道的有关方法MyService，它不需要。换句话说，如果MyClient只需要的功能C()和D()，然后代替

class MyService 
{
    public void A();
    public void B();
    public void C();
    public void D();
}

/*client code*/      
MyService service = ...;
service.C(); 
service.D();

我们应该将MyService's方法隔离到特定于客户端的接口中：

public interface ISmall_1
{
     void A();
     void B();
}

public interface ISmall_2
{
     void C();
     void D();
}

class MyService:ISmall_1, ISmall_2 
{ ... }

/*client code*/
ISmall_2 service = ...;
service.C(); 
service.D();

因此，在前者的定义下，ISP的目标是“ 使实现IFat接口的类的寿命变得更容易 ”，而在后者的定义下，ISP的目标是“ 使客户机调用MyService的方法的寿命变得更容易 ”。

ISP的两个不同定义中的哪一个实际上是正确的？

@MARJAN VENEMA

1。

因此，当您要将IFat拆分为较小的接口时，应根据成员的内聚性决定在哪种方法最终决定ISmallinterface。

虽然将聚合方法放在同一个接口中是有意义的，但我认为使用ISP模式时，客户端的需求要优先于接口的“聚合性”。换句话说，我认为与ISP一起，我们应该将特定客户端所需的那些方法集中在同一个接口中，即使这意味着将那些出于凝聚力也应该放在同一个接口中的方法留在该接口之外？

因此，如果有大量的客户，将永远只能需要通话CutGreens，但不能也GrillMeat，然后坚持ISP模式，我们应该只把CutGreens里面ICook，但也没有GrillMeat，尽管这两种方法都具有高度凝聚力？

2。

我认为您的困惑源于第一个定义中的一个隐含假设：实施类已经遵循单一责任原则。

通过“实现不遵循SRP的类”，您是指实现的那些类IFat还是实现ISmall_1/的类ISmall_2。我假设您是指实现的类IFat？如果是这样，为什么您认为他们还没有遵循SRP？

谢谢

两者都是正确的

以我的理解，ISP（接口隔离原理）的目的是保持接口小而集中：所有接口成员都应具有很高的凝聚力。两种定义都是为了避免“无所不包的大师”的接口。

接口隔离和SRP（单一职责原理）具有相同的目标：确保小型，高度凝聚力的软件组件。他们互相补充。界面隔离可确保界面小巧，集中且高度凝聚。遵循单一责任原则可确保班级规模小，重点突出且凝聚力强。

您提到的第一个定义集中在实现者上，第二个定义在客户端上。与@ user61852相反，我将其视为接口的用户/调用者，而不是实现者。

我认为您的困惑源于第一个定义中的一个隐含假设：实施类已经遵循单一责任原则。

对我来说，以客户端为接口的调用者的第二个定义是达到预期目标的更好方法。

隔离

在您的问题中，您声明：

因为通过这种方式，我的MyClass只能实现所需的方法（D（）和C（）），而不必强行为A（），B（）和C（）提供虚拟实现：

但这正在颠覆世界。

• 实现接口的类不会在实现的接口中规定其需要的内容。
• 接口指示实现类应提供的方法。
• 接口的调用者实际上是那些决定它们需要接口提供哪些功能以及实现者应该提供什么功能的调用者。

因此，当您打算拆分IFat为较小的接口时，ISmall应根据成员的凝聚力决定哪种方法最终在哪个接口中确定。

考虑以下接口：

interface IEverythingButTheKitchenSink
{
     void DoDishes();
     void CleanSink();
     void CutGreens();
     void GrillMeat();
}

您要输入哪种方法ICook，为什么？您是否会因为碰巧拥有一个可以做到这一点的类以及一些其他事情而与其他任何方法都不一样而将CleanSink它们放在一起GrillMeat吗？还是将其分为两个更紧密的接口，例如：

interface IClean
{
     void DoDishes();
     void CleanSink();
}

interface ICook
{
     void CutGreens();
     void GrillMeat();
}

接口声明说明

接口定义最好应单独放在一个单独的单元中，但是如果绝对需要与调用者或实现者一起使用，则它实际上应该与调用者一起存在。否则，调用者将立即依赖于实现者，这完全破坏了接口的目的。另请参见：在与基类相同的文件中声明接口，这是一种好习惯吗？关于程序员，为什么我们应该将接口与使用它们的类而不是实现它们的类放在一起？在StackOverflow上。

您将“四人一组”文档中使用的“客户端”一词与服务使用者中的“客户端”相混淆。

正如“四个帮派”定义所预期的，“客户端”是实现接口的类。如果类A实现了接口B，则他们说A是B的客户。否则，“不应强迫客户实现他们不使用的接口”这句话是没有意义的，因为“客户”（如消费者）不需要什么都没实现 仅当您将“客户端”视为“执行者”时，该短语才有意义。

如果“客户端”的意思是一个类“消费”（调用）实现大接口的另一个类的方法，则通过调用您关心的两个方法并忽略其余的方法，足以使您与其他方法分离您不使用的方法。

该原理的精神是避免“客户端”（实现接口的类）仅在关心一组相关方法时才必须实现伪方法，以便遵守整个接口。

它还旨在尽可能减少耦合量，以便在一处进行的更改造成的影响较小。通过隔离接口，可以减少耦合。

当接口执行过多操作并具有应分为几个接口而不是一个接口的方法时，就会出现该问题。

您的两个代码示例都可以。仅在第二个示例中，您假定“客户端”的意思是“使用/调用另一个类提供的服务/方法的类”。

我发现在您给出的三个链接中所解释的概念没有矛盾。

只要在SOLID对话中明确指出“客户”是实施者即可。

ISP的全部目的是隔离客户端，使其对服务的了解超出其所需要了解的范围（例如，保护它免受无关的更改）。您的第二个定义是正确的。就我的阅读而言，这三篇文章中只有一篇提出了其他建议（第一篇），这完全是错误的。（编辑：不，没有错，只是误导。）

第一个定义与LSP紧密相关。