Какая польза от интерфейса, который подразумевает определенную реализацию?

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

Интерфейс должен просто определять контракт и не должен полагаться на то, что он подразумевает, как код должен быть реализован, кроме как для удовлетворения требований контракта.

Если вы хотите подразумевать определенные пути к коду, то вам лучше иметь базовый класс, который реализует интерфейс и наследуется от него, как и в случае базового класса, у вас есть некоторый уровень контроля над потоком кода, но при этом обеспечивается точки входа для пользовательских битов логики, которые будут переопределены.