Naming convention for delegates, events and event handlers?

  • Thread starter Thread starter jjkboswell
  • Start date Start date
J

jjkboswell

I'm trying to pin down a good naming convention for the 3 things
required to implement an event.

You need:
1) a delegate
2) an event
3) an event handler

Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
or suitable or just plain wrong.

Cheers

Boz

delegate void DataAvailableEventHandler(string data);

class ServerClass
{
public event DataAvailableEventHandler DataAvailable;

public FireEvent()
{
if (DataAvailable != null)
{
DataAvailable("bang");
}
}
}

class ClientClass
{
public ClientClass(ServerClass server)
{
server.DataAvailable += new
DataAvailableEventHandler(ServerClass_DataAvailable);
}

private ServerClass_DataAvailable(string data)
{
Trace.WriteLine("I got some data:\n" + data);
}
}
 
Boz,

#3 isn't so important, because that is a private implementation, and the
naming conventions don't deal with private members (after all, they are
private, and not exposed).

You have the naming conventions right for 1 and 2. The only thing I
would say is that your event handler should follow the pattern for events
already established.

This means that you have two parameters. The first is of type object,
named sender, which is the instance of the object that fired the event.

The second is a class that derives from EventArgs (or EventArgs itself,
if there is no extra information).

In this case, you would have a class named DataAvailableEventArgs which
exposes a property named Data, which would expose your string.

Hope this helps.
 
Hello Boz

Not sure you're aware of it, but the 2.0 framework provides a generic
EventHandler.

public event EventHandler<DataAvailableEventArgs> DataAvailable;

I recently refactored a framework for 2.0 and replaced all
eventhandler-specific delegates with the generic 2.0 pattern as seen above.
 
Thanks for the tip on EventArgs. I'd heard that before and will change
my delegate to follow the conventions.

Cheers

Boz
 
We're not sure we can move to .NET 2.0 yet, but if we do we'll make use
of generics where possible.

Regards

Boz
 
Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
or suitable or just plain wrong.
Below is my understanding of a naming convention based on the Windows
Forms events. Can someone let me know if this convention is standard,
or suitable or just plain wrong.

I'm not really going to comment on the naming, but:
class ServerClass
{
public event DataAvailableEventHandler DataAvailable;

public FireEvent()
{
if (DataAvailable != null)
{
DataAvailable("bang");
}

Wrong wrong wrong! There is no difference between your

public event DataAvailableEventHandler DataAvailable;

and a

public /*event*/ DataAvailableEventHandler DataAvailable;

That is, DataAvailable is basically a public delegate field, and any
code that sees ServerClass can fire the DataAvailable event and/or
edit the invovation list.

You should be using code like

class ServerClass
{
private event DataAvailableEventHandler dataAvailable;
// Only ServerClass can touch the delegate!

public event DataAvailableEventHandler DataAvailable
// external code can only subscribe/unsubscribe
{
add {dataAvailable += value;}
remove {dataAvailable -= value;}
}

public void FireEvent()
{
if (dataAvailable != null)
{
dataAvailable("bang");
}
}
}
 
As good as that code is, if you try using his method and firing the
event, it wont let you (at least in 2.0 it wont let you).
 
Ok, I'm confused. Why can't you protect access to event delegate in
..NET 2.0? It makes sense and follows the property/field mechanism.

Boz
 
Mark said:
As good as that code is, if you try using his method and firing the
event, it wont let you (at least in 2.0 it wont let you).

Aack, you're right! I've been misunderstanding the "event DelegateType
EventName" syntax - noticed that *in class* it acts like a delegate.
Did *not* notice that out-of-class it acts like add/remove delegate.

Thanks!
 
Back
Top