【问题标题】:What would be the benefit of an interface which implies a certain implementation?暗示某种实现的接口有什么好处?
【发布时间】:2011-05-09 21:55:16
【问题描述】:

我在看这个:

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 的调用中返回。

我看不出这种技术有什么真正的好处,因为您已经必须实施并考虑两种方法来做到这一点。

您的想法 - 这种方法有什么有效的好处,还是仅仅是代码味道?

【问题讨论】:

    标签: asp.net ajax callback class-design interface-design


    【解决方案1】:

    接口应该只定义契约,不应该依赖于暗示代码应该如何实现,除了满足契约的要求。

    如果您想暗示某些代码路径,那么您最好拥有一个实现接口的基类并从该基类继承,就像使用基类一样,您确实可以在一定程度上控制代码流,同时仍然为要覆盖的自定义逻辑位提供入口点。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2010-11-26
      • 2019-11-13
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2018-02-14
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多