What is the use of an interface that implies a specific implementation?

Question

I look at this:

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

So, the pages implement this interface and look like this:

 public partial class XPage : Page, IAjaxCallbackEventHandler { // public because it 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 guarantees that the programmer will have to think about saving the response from RaiseCallbackEvent so that later it is returned from the call to GetCallbackResult .

I do not see any real advantages for this technique, since you already need to implement and think about two methods that do this.

Are your thoughts any real benefits to this approach, or is it just the smell of code?

Answer 1

The interface should simply define the contract and should not rely on to imply how the code should be implemented, except to meet the requirements of the contract.

If you want to specify specific code paths, then it would be better for you to have a base class that implements the interface and inherits it, as well as a base class that you have a degree of control over the flow of your code, while at the same time providing entry points for custom bits of logic for redefinition.