L
Leslie Sanford
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.
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.