継承とインターフェイスの分離の原則

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); 
} 

を持っていた場合、実際にあなたがTemplate method design pattern

を適用している、あなたのBaseクラスは必要ありませんSendメソッドを実装することを余儀なくされるだろう。 ので、ISPはそれを持っている方が良いであることを示唆している：

interface ISendInt 
{ 
    void Send(int n); 
} 

interface IReceiveInt 
{ 
    int Receive(); 
} 

ので、あなたのクラスは、1つまたは両方を実装することを選択することができます。また、の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（）に「依存する」という表現は、私が用語を使う方法では見ません。 Receiveが変更された場合、Concreteはどのように変更する必要がありますか？私は議論するつもりはない。 Receive（）を別の名前のメソッドまたは別のシグネチャに置き換えたとすると、Concreteは認識しません。コンクリートはReceive（）を呼び出しますか？いいえ、私はReceive（）に依存していません。

依存関係は署名OnMsg（）との関係であり、ConcreteはそのOnMsg（）契約を満たすBaseとの非常に特別な関係に参加します。

しかし、違った意味でコンクリートは、外界とのインターフェースであるBase.Receive（）に大きく依存しています。その方法がなければ誰もコンクリートの能力にアクセスすることはできません。この意味で、ConcreteはBase.Receive（）を非常に基本的なレベルで使用しています。