我是否使用正确的方法来监视创建句柄时要执行的任务? [英] Am I using the right approach to monitor the tasks I want to perform when a handle is created?

问题描述

是否有一个普遍接受的最佳实践来创建一个取消订阅的事件处理程序?

Is there a generally-accepted best practice for creating an event handler that unsubscribes itself?

例如，我想出的第一件事是:

E.g., the first thing I came up with is something like:

// Foo.cs

// ...
Bar bar = new Bar(/* add'l req'd state */);
EventHandler handler = new EventHandler(bar.HandlerMethod);

bar.HandlerToUnsubscribe = handler;

eventSource.EventName += handler;
// ...

<小时>

// Bar.cs

class Bar
{
    /* add'l req'd state */

    // .ctor

    public EventHandler HandlerToUnsubscribe { get; set; }

    public void HandlerMethod(object sender, EventArgs args)
    {
        // Do what must be done w/ add'l req'd state
        ((EventSourceType)sender).EventName -= this.HandlerToUnsubscribe;
    }
}

<小时>

要说这感觉很老套/不好，这是轻描淡写的.它与时间依赖性紧密耦合(必须在正确的时间为 HandlerToUnsubscribe 分配正确的值).我觉得在这种情况下我一定是在扮演一个复杂的角色——我错过了什么愚蠢或简单的东西吗?

---

To say that this feels hackish/bad is an understatement. It's tightly coupled with a temporal dependency (HandlerToUnsubscribe must be assigned the exact value at the exact right time). I feel like I must be playing the part of a complicator in this case--- is there something stupid or simple that I'm missing?

我正在创建 UI 和 Winforms 中的专有命令基础结构之间的绑定(使用 System.Windows.Input 中有用的 ICommand).绑定基础结构的一个方面是，在 UI 命令组件(如工具栏按钮或菜单项)之间创建绑定的用户可以选择监听命令的 CanExecuteChanged 事件，然后更新 UI 的状态基于此——通常将 Enabled 属性设置为 true 或 false.

I'm creating a binding between the UI and a proprietary commanding infrastructure in Winforms (using the useful ICommand in System.Windows.Input). One aspect of the binding infrastructure is that users who create a binding between a UI command component (like a toolbar button or menu item) have the option to listen to the command's CanExecuteChanged event and then update the UI's state based on that-- typically setting the Enabled property to true or false.

该技术通常工作得很好，但有一些方法可以在创建 ui 组件的句柄之前触发事件.我试图保证提供的处理程序不会运行，除非已创建句柄.结果，我正在考虑提供一个通用的帮助类(Bar")来帮助实现.Bar 的目标是检查是否存在适当的句柄.如果是这样，太好了！如果没有，它将订阅适当的 IsHandleCreated 事件，以便在最终创建句柄时运行提供的处理程序.(这很重要，因为客户端可以在存在句柄之前在 UI 的 .ctor 中设置它们的绑定.)但是，我希望这个订阅是完全透明的，所以我还希望每个事件处理程序自动从 IsHandleCreated 运行完成后.

The technique generally works quite well, but there are ways for the event to be fired prior to a ui component's handle having been created. I'm trying to guarantee that the provided handler isn't run unless the handle has been created. Resultantly, I'm considering providing a general helper class ("Bar") that will aid implementation. The goal of Bar is to check to see if the appropriate handle exists. If so, great! If not, it will subscribe to appropriate IsHandleCreated event so that the supplied handlers get run when the handle eventually is created. (This is important b/c the client may set their bindings in the UI's .ctor, before a handle exists.) I want this subscription to be completely transparent, however, and so I also want each event handler to automatically unsubscribe itself from IsHandleCreated once it's finished running.

我仍然在试图弄清楚这是否是一个好主意，所以我还没有概括这个概念——在这种情况下，我只是直接针对 ToolStripItems 实现它来验证这个想法是合理的.不过，我还没有卖掉它.

I'm still at a point where I'm trying to figure out if this is a good idea, so I haven't generalized the concept yet-- I've only implemented it directly against ToolStripItems in this case to verify that the idea is sound. I'm not sold on it yet, though.

我了解我还可以选择仅在创建 UI 句柄后在表单的 OnLoad 事件中(例如)强制创建绑定.我知道这行得通，我过去做过.不过，我想看看在这种情况下我是否可以缓解该特定要求.如果它甚至实用.

I understand that I also have the option of simply mandating that bindings can only be created once the UI's handle has been created, in the OnLoad event of a form (e.g.). I know that can work, I've done it in the past. I'd like to see if I can ease that particular requirement in this case though. If it's even practical.

推荐答案

Greg,

你所拥有的不是观察者模式，而是一个消息队列.所以你只是为你试图解决的问题使用了错误的设计模式.

What you have is not an observer pattern, but rather a message queue. So you're just using the wrong design pattern for the problem you're trying to solve.

使用 Queue{Action{object}} 从头开始​​实现您自己的消息队列很容易，其中对象自己排队，您只需在调用它们时将项目出队.

Its easy enough to implement your own message queue from scratch using a Queue{Action{object}}, where objects enqueue themselves, and you simply dequeue items as you invoke them.

这篇关于我是否使用正确的方法来监视创建句柄时要执行的任务?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！