繼承和接口隔離原則

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的類的方法也需要a

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（）在我使用該術語的方式。 如果接收被修改，混凝土將如何改變？ 我會爭辯，根本不是。 假設我們用不同名稱或不同簽名的方法替換Receive（），Concrete將不知道。 具體調用Receive（）嗎？ 不，所以我認為這里沒有依賴於Receive（）。

依賴是使用簽名OnMsg（），Concrete參與與Base的非常特殊的關系，履行OnMsg（）契約。

但是在不同的意義上，Concrete非常依賴於Base.Receive（），它是外部世界的接口 - 如果沒有這種方法，沒有人可以訪問Concrete的功能。 在這個意義上，混凝土“使用”Base.Receive（）在一個非常基礎的層面。