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.