隐含某种实现的接口有什么好处?

发布于 2024-11-05 21:05:05 字数 1088 浏览 4 评论 0原文

我正在看这个:

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

我看不到这种技术有任何真正的好处,因为您已经必须实现并考虑两种执行此操作的方法。

您的想法 - 这种方法有什么实际好处,或者只是一种代码味道?

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?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

2024-11-12 21:05:05

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

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

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文