Question

I’m looking at this:

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

So pages implement this interface and end up looking like this:

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;
    }

}

As far as I can tell, this interface simply ensures that the programmer will have to think about storing the response from RaiseCallbackEvent to later be returned from the call to GetCallbackResult.

I cannot see any real benefits to this technique, since you already have to implement and think about two methods which do this.

Your thoughts – any valid benefits to this approach, or is it simply a code smell?

Answer 1

The interface should just define the contract and shouldn’t be relied on for implying how the code should be implemented, other than to meet the requirements of the contract.

If you want to imply certain code paths, then you’d be better off having a base class which implements the interface and inherit from that as with a base class you do have a degree of control over the flow of your code, while still providing entry points for custom bits of logic to be overridden.