Общие EventArgs для встроенных типов

Question

Плакаты на Нужны ли классы EventArg теперь, когда у нас есть универсальные и Есть ли в .NET встроенные EventArgs ? советуют против универсальных EventArgs, по крайней мере это чувство, которое я получаю.

Оправдано ли использовать его, когда мне нужен только один из встроенных типов? В моем конкретном случае я читаю из потока через TCP, и при получении данных подписчики уведомляются.

public event EventHandler<EventArgs<string>> data_received = delegate { };

...

while (!reader.EndOfStream)
{
    if ((data = reader.ReadLine()) != "")
    {
        this.data_received(this, new EventArgs<string>(data));
    }
}

Или, может быть, событие не лучший способ передачи данных подписчикам?

Answer 1

Краткий ответ: это зависит.

Вы можете рассмотреть EventArgs<T> класс как Tuple<T> для передачи и получения данных в / из метода. В некоторых простых случаях и для внутреннего использования Tuple<T> подходит, но для более сложных случаев или для общественных мест было бы более целесообразно использовать отдельный тип.

С EventArgs<T> мы имеем более или менее одинаковую дилемму. Для внутреннего использования нормально использовать этот тип, но для публичного API это может привести к кошмару обслуживания.

В вашем конкретном случае кажется вполне приемлемым использовать EventArgs<T> на первый взгляд, но что если позже вы решите добавить к этому дополнительную информацию, например EndPoint? В этом случае вы можете использовать EventArgs<T, U> (например, Tuple<T, U>) или переключиться на пользовательский класс EventArgs. В обоих случаях вы сломаете всех своих клиентов, и если у вас только один клиент с этим кодом - все в порядке, но если нет ...

Итог, для внутренних вещей нормально использовать EventArgs, но для публичной поверхности я предлагаю использовать пользовательские аргументы событий.

P.S. Общее соглашение об именах для событий - CamelCase, и в вашем конкретном случае это означает, что DataReceived является более подходящим именем для вашего события.