如果我们传递对象本身，为什么我们需要EventArgs？ C＃

Question

I'm still new to C# and to programming. I already used WPF and looked for one of the socket practices. And I just do not get the reason of existing second argument in eventHandlers.

I'm trying to make an async server. But the in the video the programmer have added custom eventArgs to the object itself and added them to the eventHandler too. To make things a bit clearer there is the part of the code:

Buffer for received data class

class DataReceivedEventArgs : EventArgs
{
    public const int BufferSize = 1024;
    public byte[] BufferBytes;
    public int ToReceive;
    public MemoryStream BufferStream;

    // Constructor for this
    public DataReceivedEventArgs(int toReceive)...

    // Dispose function for this
    public void Dispose()...

    // Close function for stream
    private void Close()...
}

Client class

class Client
{
    private byte[] lenBufferBytes;
    private DataReceivedEventArgs receiveBuffer;
    private Socket socket;
    public IPEndPoint EndPoint...

    // Constructor for this
    public Client(Socket socket)
    {
        this.socket = socket;
        this.lenBufferBytes = new byte[4];
    }

    // Events
    public event EventHandler Disconnected;
    public event EventHandler<DataReceivedEventArgs> DataReceived;

    // Event Invokers
    protected virtual void OnDisconnected()
    {
        Disconnected?.Invoke(this, EventArgs.Empty);
    }

    protected virtual void OnDataReceived(DataReceivedEventArgs e)
    {
        DataReceived?.Invoke(this, e);
    }


}

So my questions are:

1. Why do you need to pass the same thing twice?

and

2. Why would you ever need to have eventArgs if you can store everything in the object and change object class only without code breaking if need to add new args?

Answer 1

You're not passing the same thing twice; the first parameter is the object that raised the event, the second details about the event.

One reason it's a good idea to put details inside of an event object instead of just updating the sender object is because you don't know at what point the event handler is going to act on the event; if you just stored the event details in the sender object, then you're introducing potential race conditions. Plus, it would violate the Single Responsibility Principle and confuse two different concerns.

Also, in that sample, the class isn't being added in two places; the client code just has a reference to an event instance , the server the definition of the event class .