Хорошо использовать DataEventArgs <TData> вместо настраиваемого класса данных событий?

Использует общий класс DataEventArgs<TData>, а не объявляет и использует собственный класс наследуемого класса EventArgs, в объявлении события, является нарушением конвенции "шаблон".Net Event? Или в некоторых случаях считается плохой практикой?

(Соглашение об именовании имен args - это использование имени события и добавление постфикса "EventArgs". Использование DataEventArgs<TData> исключает имя события, хотя оно показывает тип передаваемых данных.)

Возможно, вы можете утверждать, что общий класс DataEventArgs является закрытым для расширений, например добавлением другого свойства, если вы не можете изменить класс, который вы используете для TData.


Более подробное объяснение:

При объявлении стандартного делегирования делегата, который включает некоторые данные, я понимаю, что стандартное событие "шаблон" означает объявить его с помощью общего делегата EventHandler:

public event EventHandler<SomethingHappendEventArgs> SomethingHappend;

Если конкретный SomethingHappendEventArgs объявлен чем-то вдоль строк

public class SomethingHappendEventArgs : EventArgs
{
    public SomeDataType Value { get; private set; }
    public SomethingHappendEventArgs(SomeDataType data)
    {
        this.Value = data;
    }
}

При поиске по сайту я заметил, что существует несколько пространств имен Microsoft, которые поставляют общий класс DataEventArgs (включая Microsoft.Practices.Prism.Events). Однако я нигде не мог найти никаких рекомендаций или условных указаний о том, когда использовать это вместо настраиваемого класса данных событий, например SomethingHappendEventArgs или наоборот.

Итак, если есть одна часть данных, которую я хочу включить в данные события, есть ли какие-то причины, по которым я должен использовать настраиваемые классы данных событий, например SomethingHappendEventArgs, вместо объявления таких событий?

public event EventHandler<DataEventArgs<SomeDataType>> SomethingHappend;

где общий DataEventArgs может быть объявлен примерно так:

public class DataEventArgs<TData> : EventArgs
{
    public TData Value { get; private set; }
    public DataEventArgs(TData value)
    {
        this.Value = value;
    }
}

Ответ 1

Там мало причин не использовать общий подкласс EventArgs для непубличных событий. Однако для событий, которые являются частью общедоступного API, все становится немного сложнее из-за потенциальной обратной совместимости. Для публично потребляемого события создание подкласса EventArgs для конкретных событий даст вам гибкость для добавления элементов без влияния на потребителей API.

Для события, которое не является частью общедоступного API, по-прежнему существует небольшая возможная доработка, если подкласс EventArgs был изменен для определенного события, потому что общий подкласс уже не был подходящим. Однако это обычно должно быть довольно минимальным, и компилятор должен улавливать любые проблемы (используются ли методы явного или анонимного обработчика). Очевидно, что между первоначальными усилиями по разработке и потенциальными усилиями по изменению есть компромисс - я использую общий EventArg для внутренних событий, где он подходит, и мне редко нужно было изменить его после первоначального выпуск.