views:

660

answers:

4

I have this class:

public class GenericEventArgs<T> : EventArgs
{
    public GenericEventArgs() : this(default(T)) {}
    public GenericEventArgs(T value) { Value = value; }
    public T Value { get; private set; }
}

And this event handler delegate for it:

public delegate void GenericEventHandler<T>(object sender, GenericEventArgs<T> e);

I currently have these in the same file together in a namespace. Is that considered bad/messy/etc.? Cause, in general I would say that each file should contain only one class. So to have it clean I would prefer to have the GenericEventArgs class in the file alone. But then I have this GenericEventHandler<T> delegate that I am not sure where I should place. Should it have its own file? With just... that one line kind of? (and the namespace of course)

How do you usually do this?

+1  A: 

Well I'd put the GenericEventArgs<T> class in it's own file called

GenericEventArgs_T.cs in the same namespace as everything else.

And I'd put your delegate (and event if there is one) in the class that's going to have that event exposed on it.

Eoin Campbell
+1  A: 

When I wanted to create my own eventhandler delegates, I used to create one file which had the name of the EventArgs class that I used in my own eventhandler delegate. For instance 'MyEventArgs.cs'.

That file contained the MyEventArgs class, and the MyEventHandler delegate that used this class.

Now however, I use the existing generic EventHandler (EventHandler<T>), and I only have to create my custom EventArgs class. So, this 'problem' doesn't exists anymore for me. :)

Frederik Gheysels
+2  A: 

Any reason for not using EventHandler<TEventArgs>? I thought there was an equivalent EventArgs<T> but I can't see it at the moment... Anyway, I'd put GenericEventArgs in GenericEventArgs.cs

Personally, when I want to introduce my own delegate types (which is increasingly rare, to be honest) I create a Delegates.cs file with all the appropriate delegates for the namespace in. Then I know where to find them without having a file for a single declaration.

Jon Skeet
pragmatic advice
Gishu
Because the designer doesn't seem to handle events of type EventHandler<GenericEventArgs<string>> too well. Maybe that is a bug that should be reported... (http://stackoverflow.com/questions/772036/c-event-not-showing-up-in-the-property-grid)
Svish
Don't create Delegates.cs. This is creates coupling between code that you don't need.
Dave Hillier
That is, it introduces a structural dependency on all delegates when you only require one.
Dave Hillier
@Dave Hillier: What do you mean? What pragmatic disadvantage do you see here (compared with the pragmatic *advantage* of not having a bunch of tiny files containing one meaningful line each)? It's not like you specify which *source* file each individual file depends on in the first place...
Jon Skeet
Pragmatic disadvantage is it makes the code harder to understand as the delegate is not localized with the code in the problem space. To use an example from C, think of what is in stdlib.h, from the name what is in there? Is this a good grouping of functions. I don't think that it is pragmatic to create arbitrary groupings.
Dave Hillier
A: 

I'd do what you are already doing and then put all delegates that are not used for events in a separate .cs file called Delegates.cs or something similar.

Farawin