특정 구현을 암시하는 인터페이스의 이점은 무엇입니까?

Question

나는이 찾고 있어요 :

그래서 문서가이 인터페이스를 구현하는이처럼 보이는 끝낼

public interface IAjaxCallbackEventHandler : ICallbackEventHandler 
    { 
     string CallbackResponse { get; set; } 
    } 
} 

:

public partial class XPage : Page, IAjaxCallbackEventHandler { 
    // public because it's an interface, but really an implementation detail ;-(
    public string CallbackResponse { get; set; } 

    // implementing underlying ICallbackEventHandler interface 
    public void RaiseCallbackEvent(string eventArgument) 
    { 
     try 
     { 
      CallbackResponse = SomeOperation(eventArgument); 
     } 
     catch (Exception ex) 
     { 
      CallbackResponse = ex.ToString(); 
     } 
    } 

    // implementing underlying ICallbackEventHandler interface 
    public string GetCallbackResult() 
    { 
     return CallbackResponse; 
    } 

} 

지금까지 내가 말할 수있는 건,이 인터페이스는 단순히 보장

그 프로그래머 것 RaiseCallbackEvent의 응답을 나중에 GetCallbackResult에 대한 호출에서 반환하도록 생각해야합니다.

이 기술을 구현 한 두 가지 방법을 이미 구현하고 생각해야하기 때문에이 기술에 대한 실질적인 이점은 없습니다.

귀하의 의견 -이 접근법에 대한 유효한 혜택입니까 아니면 단순히 코드 냄새입니까?

Answer 1

인터페이스는 계약을 정의해야하며 계약 요구 사항을 충족시키는 것 이외에 코드 구현 방법을 암시해서는 안됩니다.

특정 코드 경로를 암시하고 싶다면 인터페이스를 구현하는 기본 클래스를 사용하는 것이 더 좋을 것입니다. 기본 클래스를 사용하면 코드 흐름을 제어 할 수있는 것처럼 상속받을 수 있습니다. , 로직의 사용자 정의 비트에 대한 엔트리 포인트를 여전히 제공합니다.