Two questions regarding events

Question

I would like to know:

1. Subscriber is a name for class that subscribes for the event or also for the method that is handling the event? I mean, does it make sense to say "subscribe method to event"?

2. On MSDN it says that event delegate should have exactly 2 arguments. Not sure what it means as I often create events with my custom delegate that has eg none or one argument.

Answer 1

1) Yes, it definitely makes sense to talk about subscribing a method to an event. You can actually think of there being three entities involved:

• The subscribing code which is actually performing the subscription itself
• The event publisher
• The handler which is being subscribed; this is often - but not always - code in the same class as the subscribing code

2) You certainly can create events using delegates with any number of parameters. The convention is that delegates used in events have two parameters: a "sender" and an "argument" derived from EventArgs . For example, this means that you can subscribe a handler from a method with a signature of void Foo(object sender, EventArgs e) to any event following the convention.

Answer 2

A subscriber is a method that is added as an event handler.

Standard practice is to use the EventHandler<T> delegate for events; this has two arguments.
However, you can create your own events with any number of arguments.

Answer 3

I'll concentrate on the second point. As Jon pointed out, you can use your own delegates for events. But you rarely should. Even if you don't care about conventions, look at it this way: whenever you use your own events with custom delegates, you have the following code besides the event field itself:

• Your custom delegate
• Event handlers (methods with matching signature) - sometimes a lot of them
• Event invocation points (where you need to pass all the parameters)- sometimes a lot of them
• I also tend to create the InvokeMyEvent methods that do the nullity checking and other stuff that needs to be done

You have to change all of these if you decide to add or remove a parameter or change a parameter type.

Now, if you create your own class that inherits EventArgs or use the EventArgs<T> , you have:

• Your CustomEventArgs class
• Event handlers
• Event invocation points
• InvokeMyEvent methods.

Whenever you decide to change the event args you have to change only your custom args class and some of the event invocation points. "Some", because you can provide suitable default values for fields of your args class and only provide the values when you need it.

Most of good/bad practice talks are focused on one thing - ease of change . Changes always happen. The fewer things you have to alter when they do, the better. Design has a lot of iterations and the odds are that you'll have to change your interfaces and types a lot. You don't want to change tens of signatures whenever you decide that you don't need the parameter anymore. So use the EventArgs or EventArgs<T> and save yourself some headache.

Another minor point is that you'll probably want to declare some methods that take care of raising the events, like this:

public static public void FireEvent<T>(this EventHandler handler, object sender, EventArgs<T> e)
    where T : EventArgs
{
    if (handler != null)
        handler(sender, e);
}

If all your events are EventHandler -based, you can use one all-purpose method for things like that. If not, then you'll eventually have tens of them.