加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程开发 > asp.Net > 正文

asp.net – 界面的好处是什么意味着某种实现?

发布时间:2020-12-16 09:45:00 所属栏目:asp.Net 来源:网络整理
导读:我在看这个: public interface IAjaxCallbackEventHandler : ICallbackEventHandler { string CallbackResponse { get; set; } }} 所以页面实现了这个界面,最终看起来像这样: public partial class XPage : Page,IAjaxCallbackEventHandler { // public be
我在看这个:

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

我看不出这种技术有什么好处,因为你已经必须实现并考虑两种方法来实现这一点.

您的想法 – 这种方法的任何有效好处,还是仅仅是代码味道?

解决方法

接口应该只定义合同,不应该依赖于暗示代码应该如何实现,而不是满足合同的要求.

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

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读