Какая польза от интерфейса, который подразумевает определенную реализацию? - PullRequest
4 голосов
/ 10 мая 2011

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

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.

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

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

1 Ответ

2 голосов
/ 10 мая 2011

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

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

...