继承与界面分离原理

Question

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

例如：

abstract class Base
{
    public void Receive(int n)
    {
        // . . . (some important work)

        OnMsg(n.ToString());
    }

    protected abstract void OnMsg(string msg);
}

class Concrete : Base
{
    protected override void OnMsg(string msg)
    {
        Console.WriteLine("Msg: " + msg);
    }
}

Concrete依赖于方法Base.Receive(int n)，但它从不使用它。

UPD

我使用的定义：

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

Answer 1

我想你误解了界面隔离原则的意思。在您的例子中，您很好，并且没有“强制”任何实现。实际上，您正在应用模板法设计模式

如果你有一个假设

interface ICommunicateInt
{
  int Receive();
  void Send(int n);
}

为了实现它，您的Base类将被迫实现它不需要的Send方法。因此，ISP建议，最好是：

interface ISendInt
{
  void Send(int n);
}

interface IReceiveInt
{
  int Receive();
}

因此，您的类可以选择实现一个或两个。另外，在其他类中需要一个可以发送Int的类中的方法可能需要

void Test(ISendInt snd)
// void Test(ICommunicateInt snd) // Test would "force" snd to depend on 
                                  // a method that it does not use 

Answer 2

我不认为具体“依赖”于Base.Receive()这个术语的使用方式。如果接收被修改，具体需要如何改变？我会争辩的，一点也不。假设我们用一个不同名称的方法或一个不同的签名替换了接收()，混凝土将不知道。具体呼叫接收()吗？不是的。因此，我在这里看不到对接收()的依赖。

依赖关系带有签名的OnMsg()，具体参与了与Base的非常特殊的关系，从而实现了OnMsg()契约。

但是，在不同的意义上，混凝土很大程度上依赖于Base.Receive()，即它与外部世界的接口--没有这种方法--没有人能够访问混凝土的能力。从这个意义上说，具体的“使用”Base.Receive()在一个非常基本的级别上。