using "sender" vs. custom EventArgs
Consider this scenario. I have an object, lets call it.... Foo. Foo raises a simple event named "Loaded". As part of the information for the event, consumers will need to know which foo object raised the event. Our team has adopted the following pattern.
1) Create a new class that inherits from EventArgs - for example, FooEventArgs : System.EventArgs.
2) Add a property of type Foo to the FooEventArgs, which is set by being passed in via the constructor.
3) Declare the event using the generic version of EventHandler, so
public event EventHandler<FooEventArgs> Loaded;
4) Raise the event from the Foo class with the following signature:
Loaded(this, new FooEventArgs(this));
Essentially what this does is makes the "sender" the foo object, but it also puts the foo object reference into the event argument as a strongly typed property.
One advantage for doing this is that no one has to bother with casting "sender" when they handle the event, which lowers the coupling between the event consumer and the event raiser. Another "advantage" is that if the type of the event raiser ever has to change, and hence the strongly typed property (which hopefully never happens), then instead of simply having code start to fail on the cast when it comes out as null, the API actually breaks so it can be fixed at compile time.
To me, this pattern seems like it might be overkill. Should they be trusting the "sender" parameter more, and ditching the custom event arguments? My team argues that no one really uses the sender parameter. What's the best practice for passing out a reference to the event-raising object?
EDIT: Great feedback so far, I'll leave this open for another day or so before I accept one.
The common pattern is to use sender and not add the sender separately to the EventArgs. The custom EventArgs is used for other state like a tree node for a tree event, a (settable) boolean for a cancelable event etc.
We use the common pattern since it is used by the BCL classes also, and making a difference for "self-made events" is potentially confusing. Also, we have a global IoC publisher-subscriber pattern but this one only works with the normal EventHandler delegate signature, since the types are not known in advance. In this case, a cast (for instance to a custom EventArgs) is necessary anyways, so we might just as well cast the sender.
I don't think this is overkill. I agree with the advantages you state for having a separate FooEventArgs class. One other advantage to doing it that way is that if you need to add more information to the event in the future you can just add more properties to the FooEventArgs and you don't need to change the delegate.
I would say that you drop the subclass of EventArgs and use the sender property to identify the sender of the event. I think that the argument for following convention has merit, but the parameter in the EventArgs is not necessary. I personally would drop it and just use the sender property.
If you want to pass it as a strong type, you could also just create a custom delegate to use for your event...
public delegate void LoadedHandler(FooEventArgs args);
that way you could have it as a strong type... reusing delegates is great, but if they don't fit what you are trying to do you shouldn't feel constrained to only use the built in ones.
链接地址: http://www.djcxy.com/p/54052.html上一篇: 如何模拟需要转换到另一个接口的接口？
下一篇: 使用“发件人”与自定义EventArgs