I know about C# events and delegates. I find them incredibly useful for event-dr
ID: 645917 • Letter: I
Question
I know about C# events and delegates. I find them incredibly useful for event-driven sub-systems. One thing I don't understand, however, is why all the .NET documentation for events uses a very specific pattern for delegates:
public class Foo
{
public class CustomEventArgs : System.EventArgs
{
...
}
public delegate void CustomEventHandler(object sender, EventArgs e);
public event CustomEventHandler CustomEvent;
public void OnCustomEvent(int x, float y, bool z)
{
if (CustomEvent != null)
CustomEvent(this, new CustomEventArgs(x, y, z));
}
}
I find this method of declaring and using delegates incredibly unsecure and clunky compared to using custom delegates. For example:
public class Foo
{
public delegate void CustomEventHandler(Foo foo, int x, float y, bool z);
public event CustomEventHandler CustomEvent;
public void OnCustomEvent(int x, int y, int z)
{
if (CustomEvent != null)
CustomEvent(this, x, y, z);
}
}
Besides the obvious advantage of "It's the pattern most familiar to .NET programmers", I fail to see any other practical advantages to using delegates with the void CustomEventHandler(object sender, CustomEventArgs e) signatures as opposed to custom delegates. Mainly, you have the following advantages with custom delegates:
You can guarantee the sender is of a specific type.
You don't need a whole new class just to pass the event data, leading to messier code and name pollution
I would be interested to know if there are any other advantages to using the .NET pattern for events and delegates that I might be missing.
Edit:
Mainly as a response to @MainMa, I wanted to give a more concrete example. The example is a simple representation of a character with a concept of health and death. The character throws events when its hurt, or dies. Consider the scenario below, using custom delegates:
public class Character
{
public delegate void DeathEventHandler(Character character);
public delegate void HurtEventHandler(Character character, float damage);
public event DeathEventHandler DeathEvent;
public event HurtEventHandler HurtEvent;
public bool IsDead { ... }
public void ApplyDamage(float damage)
{
...
OnHurt(damage);
...
if (IsDead)
OnDeath();
}
public void OnHurt(float damage)
{
if (HurtEvent != null)
HurtEvent(this, damage);
}
public void OnDeath()
{
if (DeathEvent != null)
DeathEvent(this);
}
}
To me, this is simple. It separates concerns, and enforces encapsulation. A handler that is only concerned about the death of a character doesn't need to know how much damage was applied to the character before death. So on and so forth.
Now compare this to the .NET pattern:
public class Character
{
public class CharacterHurtEventArgs : EventArgs
{
public float Damage { ... }
public bool Dead { ... }
}
public event EventHandler<CharacterHurtEventArgs> HurtEvent;
public event EventHandler<EventArgs> DeathEvent; // No args ...?
// ... The rest is the same story as above more or less ...
}
Using this, I've just added an extra class. The handler still needs different delegates for these events, and there is no guarantee that the object which died was a character. Anything could throw this.
Of course, going by @MainMa's suggestion, we could change this into:
public class Character
{
public class HealthConditionEventArgs : EventArgs
{
public float Damage { ... }
public bool Dead { ... }
public float Hitpoints { ... }
...
}
public event EventHandler<HealthConditionEventArgs> HealthConditionChangedEvent;
public void ApplyDamage(float damage)
{
...
HealthConditionChangedEventArgs e = new HealthConditionChangedEventArgs();
...
OnHealthConditionChanged(e);
...
}
public void OnHealthConditionChanged(HealthConditionEventArgs e)
{
if (HealthConditionChangedEvent != null)
HealthConditionChangedEvent(e);
}
}
This is slightly neater, but it eliminates separation of concerns. Now if the handler only cares about death, it will have to receive all hurt events. Of course, we could have separate events taking in the same event args, but you'd still be passing around the entire character health condition as part of the event. Again, if you care only about death, there is no need for the handler to know any more than the fact that the character died.
In my opinion, the first example, however, resolves all these encapsulation issues. Discrete delegates for discrete events, with only the necessary information passed in each event. No new classes either.
Explanation / Answer
Let's imagine an example of a presentation layer. The layer has mouse interactions: every time the user moves a mouse, an event telling which mouse moved (imagine the user may have multiple mice) and how the mouse moved can be raised.
With your approach, the draft code would be:
public delegate void MouseMovedHandler(
PresentationLayer l, Guid mouseId, int fromX, int fromY, int toX, int toY);
It will obviously be quickly refactored into:
public delegate void MouseMovedHandler(
PresentationLayer l, Guid mouseId, Coord from, Coord to);
But then, you'll find that you want to know, for instance, the distance between from and to. So you'll create a Line class, defined by two points, and your delegate will become:
public delegate void MouseMovedHandler(PresentationLayer l, Guid mouseId, Line motion)
Better. Now, what if we want to be able to make a difference between a simple line and a motion of a specific, identified mouse? Right, we'll end up creating the class:
class MouseMotion : Line
{
public Mouse Mouse { get; }
public Line Motion { get; }
...
}
public delegate void MouseMovedHandler(PresentationLayer l, MouseMotion motion)
Now, there is a location in your app where you need to track every possible input: mouse motion, mouse button clicks, keyboard strokes. You need that because your application starts background processing when the user is not doing anything, but should stop it and free the resources to the UI if the user is using your app.
This means that now, you need something common between MouseMotion, MouseButtonChange and KeyboardStroke. Something like IEvent. Or wouldn't it be easier to simply use EventArgs?
So you end up with:
class MouseMotionEventArgs: EventArgs { ... }
public delegate void MouseMovedHandler(PresentationLayer l, MouseMotionEventArgs motion)
Except that you could avoid the delegate, as explained at the beginning of the answer. You can now either stick with the delegate in order to have your strongly typed PresentationLayer you probably don't need most of the time, or replace it with a lousy object by using EventHandler<MouseMotionEventArgs>.
The previous version of the answer, for the sake of completeness:
Is there a reason you create a CustomEventHandler instead of using EventHandler<CustomEventArgs>?
With the generic EventHandler<T>, the code starts looking like this:
public class Foo
{
public event EventHandler<3DPointChangedEventArgs> CustomEvent;
public void OnCustomEvent(3DPoint point)
{
if (CustomEvent != null)
{
CustomEvent(this, (3DPointChangedEventArgs)point);
}
}
}
Now, compare it to the code you suggested:
Yours is longer. Chances are, your colleagues will refactor x, y and z into 3DPoint object, making it a bit shorter.
Yours doesn't match the convention used in .NET Framework. Therefore, it will be difficult to know how to use it.
The one used in .NET Framework makes it possible