Блог

Я смотрю на это:

 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 .

Я не вижу никаких реальных преимуществ в этой технике, поскольку вам уже нужно реализовать и подумать о двух методах, которые это делают.

Ваши мысли — есть ли какие-либо действительные преимущества в этом подходе, или это просто запах кода?

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

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