471,337 Members | 1,158 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,337 software developers and data experts.

EventArgs design question

I have a hierarchy of message classes. Many times when messages are
created/received by a class, an event is generated to let the outside
know. Also, the message is passed along when raising the event.

To follow the .NET event guidelines, each message class therefore needs
its own EventArgs derived class to represent it. The problem is that
these EventArgs classes do not add anything of value themselves. There
is no additional event data they can contain other than the message
itself.

So I was thinking about replacing the message classes with the EventArgs
classes. In other words, put all of the properties and methods that are
in the message classes into the EventArgs classes. Since the message
classes are small and immutable, I don't see any negative side-effects
from doing this.

The problem is that there are times when you need a message class object
that is not the result of an event. In those situations, you would be
working with an EventArgs object when no event has occurred. That seems
a little strange.

This is all a matter of design and convention. Seems like in my desire
to follow guidelines, I'm lead to a compromise that's less than optimum.

At any rate, I was happy to see the generic EventHandler<TEventArgs> in
the latest version of the .NET Framework. I can see reasons against
this, but a generic EventArgs<TEventData> class might come in handy
here, too.
Jan 13 '06 #1
3 4562
Hi Leslie,

The EventArgs class was designed to be inherited. It doesn't contain any
public data. When you inherit it, you provide the derived class with your
own data. In your case, your Message class would be the data.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

"Leslie Sanford" <ja**********@BiteMeHotmail.com> wrote in message
news:Pu********************@comcast.com...
I have a hierarchy of message classes. Many times when messages are
created/received by a class, an event is generated to let the outside know.
Also, the message is passed along when raising the event.

To follow the .NET event guidelines, each message class therefore needs
its own EventArgs derived class to represent it. The problem is that these
EventArgs classes do not add anything of value themselves. There is no
additional event data they can contain other than the message itself.

So I was thinking about replacing the message classes with the EventArgs
classes. In other words, put all of the properties and methods that are in
the message classes into the EventArgs classes. Since the message classes
are small and immutable, I don't see any negative side-effects from doing
this.

The problem is that there are times when you need a message class object
that is not the result of an event. In those situations, you would be
working with an EventArgs object when no event has occurred. That seems a
little strange.

This is all a matter of design and convention. Seems like in my desire to
follow guidelines, I'm lead to a compromise that's less than optimum.

At any rate, I was happy to see the generic EventHandler<TEventArgs> in
the latest version of the .NET Framework. I can see reasons against this,
but a generic EventArgs<TEventData> class might come in handy here, too.

Jan 14 '06 #2
As an aside - I use the following quite a bit:

[System.ComponentModel.ImmutableObject(true)]
public class SimpleEventArgs<T> : EventArgs {
private readonly T _value;
public T Value { get { return _value; } }
public SimpleEventArgs(T message) {
_value = message;
}
}
public event EventHandler<SimpleEventArgs<string>> SomeEvent;

This allows me to include a single, strongly typed, object (message) in my
event definition at no cost in terms of typing.

Marc

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:e$**************@TK2MSFTNGP10.phx.gbl...
Hi Leslie,

The EventArgs class was designed to be inherited. It doesn't contain any
public data. When you inherit it, you provide the derived class with your
own data. In your case, your Message class would be the data.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.

"Leslie Sanford" <ja**********@BiteMeHotmail.com> wrote in message
news:Pu********************@comcast.com...
I have a hierarchy of message classes. Many times when messages are
created/received by a class, an event is generated to let the outside
know. Also, the message is passed along when raising the event.

To follow the .NET event guidelines, each message class therefore needs
its own EventArgs derived class to represent it. The problem is that
these EventArgs classes do not add anything of value themselves. There is
no additional event data they can contain other than the message itself.

So I was thinking about replacing the message classes with the EventArgs
classes. In other words, put all of the properties and methods that are
in the message classes into the EventArgs classes. Since the message
classes are small and immutable, I don't see any negative side-effects
from doing this.

The problem is that there are times when you need a message class object
that is not the result of an event. In those situations, you would be
working with an EventArgs object when no event has occurred. That seems a
little strange.

This is all a matter of design and convention. Seems like in my desire to
follow guidelines, I'm lead to a compromise that's less than optimum.

At any rate, I was happy to see the generic EventHandler<TEventArgs> in
the latest version of the .NET Framework. I can see reasons against this,
but a generic EventArgs<TEventData> class might come in handy here, too.


Jan 14 '06 #3
Minor note: param name "message" was unintentional (leftover from
refactoring); should be value.

Marc
Jan 14 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Don Vaillancourt | last post: by
2 posts views Thread by David Lozzi | last post: by
17 posts views Thread by tshad | last post: by
5 posts views Thread by SamSpade | last post: by
19 posts views Thread by neelsmail | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.