Home/ Questions/Q 6611385
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T19:57:46+00:00

I was reading this page and I noticed how it said this is standard

  • 0

I was reading this page and I noticed how it said this is standard guidelines:

The .NET Framework guidelines indicate that the delegate type used for an event should take two parameters, an “object source” parameter indicating the source of the event, and an “e” parameter that encapsulates any additional information about the event.

I can understand how having an object sender could be useful in some circumstances, but I could see the exact opposite in others. For example,

  1. What if a class handling the event should not have any knowledge about who fired it? Coupling, cohesion, and all of that.

  2. In my case, I already have a reference to the object as a member variable. That is how I subscribe to the event. There will only ever be one instance of it so there’s no reason to cast the sender object rather than just using the member variable.

  3. In my program the sender object should not be known at all to the clients. It’s hard to explain what I am doing but basically I have a class with an internal constructor within a library that is used by two other classes also within that library. My client classes are subscribing to events from those two classes but the events are originally invoked from this internal class that clients should not have any knowledge of.

  4. It is confusing to clients of the event handler. Libraries should be simple to understand and in my case, there is no reason to ever use the sender variable. None. Then why include it?

That being said, why does Microsoft indicate that event handlers should follow these guidelines? Isn’t it not always the best choice?

EDIT: Thanks for the replies everyone. I’ve decided to go with the majority and use EventHandler<T> for all my events in this library.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think the reason for the pattern is to enforce some consistency. The sender parameter allows re-use of a single handler for multiple publishers (buttons, tables).

    To address your points:

    1) simply don’t use it. That is common and doesn’t really hurt any good practice.

    2) that’s OK, again ignore the sender

    3) is in total contradiction of what you said under 2) …
    And for the rest it is the same as 1). You could even consider passing null as sender.

    4) “then why include it” – there are other use cases that do require the sender.

    But do note this is just a guideline for libraries confirming to the BCL.
    Your case sounds more like a specific application (not a library) so feel free to use any parameter scheme you like. The compiler won’t complain.

    • 0