상속 및 인터페이스 분리 원칙

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 방법을 구현하도록 강요 될 것이다.

interface ISendInt 
{ 
    void Send(int n); 
} 

interface IReceiveInt 
{ 
    int Receive(); 
} 

그래서 수업이 하나 또는 모두를 구현하도록 선택할 수 있습니다 는 그래서, ISP는 가지고 더 나은 것을 제안합니다. 또한 int를 보낼 수있는 클래스가 필요 다른 클래스의 메소드는, 수신하는 경우 OnMsg 이제까지 불리는 것이 얼마나하는

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

Answer 2

Concrete는 Base.Receive()에 따라 달라집니다. 용어를 사용하는 방식은 다릅니다. Receive가 수정되면 Concrete를 어떻게 변경해야합니까? 나는 전혀 논쟁하지 않을 것이다. Receive()를 다른 이름의 메서드 또는 다른 서명으로 대체했다고 가정하면 Concrete는 인식하지 못합니다. Concrete는 Receive()를 호출합니까? 그래서 Receive()에 의존하지 않습니다.

의존성은 OnMsg() 서명과 관련이 있으며, Concrete는 OnMsg() 계약을 이행하면서 Base와 매우 특별한 관계에 참여합니다.

그러나 다른 의미에서 Concrete는 외부 세계와의 인터페이스 인 Base.Receive()에 크게 의존합니다. 그 방법이 없으면 누구도 콘크리트의 기능에 액세스 할 수 없습니다. 이러한 의미에서 Concrete는 Base.Receive()를 매우 근본적인 수준에서 사용합니다.