C# simple Event Raising - using “sender” vs. custom EventArgs

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

As far as recommended practices go, I've seen null supplied as sender in Windows Workflow Foundation quite a lot. Ideally, your subscribers should be oblivious of the object that raises events.

So if you'd need to pass the caller object as a whole to handlers, you'd have to place it in an EventArgs-derived object. Alternately, I prefer to explicitly pass the bits and pieces of Event raiser's/caller's state instead of the whole thing.

Well, sometimes it's easier to think dotNET 1.1, where

Control.Invoke()

is used as frequently as

int i;

Answer 5

I would say convention has a lot going for it. There is less to maintain in the longer run - esp. if you get new people in.

Answer 6

I guess it's a matter of preference to some degree but in my case when I read the consumers will need to know which foo object raised the event. I immediately thought that you can get the object which raised the event from the sender argument so what's the problem?

Your team has some valid points (in having strongly typed property), but I'd say that working with the framework guidelines instead of inventing your own would be a better decision in the long run.