Geek Answers Handbook

The code version of the event signature in .NET.

Previous messages:

Event signature in .NET - using a strong typed "Sender"?

In a C # event handler, why should the sender parameter be an object?

Microsoft conventions and recommendations force .NET users to use a special template for creating, creating and processing events in .NET.

Event Design Guides http://msdn.microsoft.com/en-us/library/ms229011.aspx states that

Citation:

The following conventions are observed in the signature of the event handler:

  • The return type is Void.

  • The first parameter is called the sender and is of type Object. This is the object that raised the event.

  • The second parameter is called e and is of type EventArgs or a derived class of EventArgs. This is event-specific data.

  • The method takes exactly two parameters.

These conventions tell developers that the following (next) shorter and more obvious code is evil:

public delegate void ConnectionEventHandler(Server sender, Connection connection); public partial class Server { protected virtual void OnClientConnected(Connection connection) { if (ClientConnected != null) ClientConnected(this, connection); } public event ConnectionEventHandler ClientConnected; }

and (the following) longer and less obvious code is good:

 public delegate void ConnectionEventHandler(object sender, ConnectionEventArgs e); public class ConnectionEventArgs : EventArgs { public Connection Connection { get; private set; } public ConnectionEventArgs(Connection connection) { this.Connection = connection; } } public partial class Server { protected virtual void OnClientConnected(Connection connection) { if (ClientConnected != null) ClientConnected(this, new ConnectionEventArgs(connection)); } public event ConnectionEventHandler ClientConnected; }

Although these recommendations do not indicate why it is so important to follow these conventions, forcing developers to act like monkeys who do not know why and what they are doing.

IMHO, Microsoft's event logging conventions for .NET are bad for your code because they cause extra effort with zero efficiency in coding, coding, coding:

  • Coding "(MyObject) sender" (not to mention 99% of situations that do not require a sender at all)
  • Encoding retrieved from "MyEventArgs" for data passed inside an event handler.
  • Coding splits (calling "e.MyData" when data is required instead of "data")

It is not so difficult to do this, but in practical terms, what we lose when we disagree with Microsoft agreements, except that people perceive you as a heretic because your act of confrontation with Microsoft agreements borders on blasphemy :)

Do you agree?

+4
source share
4 answers

As for having a strongly typed sender, I often wondered what I was.

As for EventArgs, I would recommend that you use the intermediate EventArgs class, because you might want to add information about future events that you currently do not anticipate. If you used the specific EventArgs class all the time, you can simply change the class itself and the code in which it runs. If you pass the connection according to your example, you will have to reorganize each event handler.

Edit

Jim Michelle made a good point in his comments. By providing an object to the sender, we allow the same event method to be potentially reused to handle multiple events. For example, say that the grid should be updated if:

  • user clicks the refresh button or
  • the system detects that a new record has been downloaded from the server.

Then you can say something like this:

 serverBus.EntryReceived += RefreshNeededHandler; refreshButton.Click += RefreshNeededHandler; ... public void RefreshNeededHandler(object sender, EventArgs args) { ... }

Of course, in practice, I almost never had calls for reuse of this kind, while the first thing I tend to in many cases distinguishes sender from the type of object that I know should be. If I want to reuse handlers like this, I think that it would be simple enough to make two handlers, which both call the same convenience method. For me, an event handler is supposed to handle a specific type of event for a specific group of objects. So I'm personally not sure if the object sender approach is the best deal.

However, I can imagine cases when it would be very convenient, for example, if you want to register every event that is triggered.

+3
source

Problems you will have:

  • When you add another argument, you will have to change your handler signature event.

  • When a programmer first looks at your code, your event handlers will not look like event handlers.

Especially the latter can scare you a lot more time than writing a 5-line class.

+3
source

The biggest problem that I see in non-compliance with the convention is that you are going to confuse the developers who are used to handle events the way the execution library does. I will not say that the agreement is good or bad, but this, of course, is not evil. .NET developers know and understand how to work with events that are written in accordance with Microsoft recommendations. Creating your own event processing engine in addition to this can be more efficient at runtime and can even lead to cleaner code. But it will be different, and in the end you will get two "processing" of event processing.

My position is that it is better to use a single standard that is different from the ideal (as long as it is not terribly violated) than for two competing standards.

+2
source

I used strongly typed events (instead of an object, since it saves me from throwing), it’s really not that difficult to understand, “oh, look, they used a type that is not an object”

As for eventArgs, you should use it if the object changes according to @StriplingWarrior's answer.

I don’t understand why the developers confuse it?

+1
source

More articles:


All Articles