Если событие, которое не имеет аргументов, определяет его собственные собственные EventArgs или просто использует System.EventArgs вместо этого?

У меня есть событие, которое в настоящее время определено без аргументов событий. То есть, EventArgs, который он отправляет, является EventArgs.Empty.

В этом случае проще всего объявить обработчик события как:

EventHandler<System.EventArgs> MyCustomEvent;

Я не планирую добавлять какие-либо аргументы к этому событию, но возможно, что в будущем любой код может измениться.

Поэтому я склоняюсь к тому, что все мои события всегда создают пустой тип аргументов arg, который inheretis от System.EventArgs, даже если в настоящее время нет аргументов событий. Что-то вроде этого:

public class MyCustomEventArgs : EventArgs
{
}

И тогда мое определение события станет следующим:

EventHandler<MyCustomEventArgs> MyCustomEvent;

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

Я склоняюсь к созданию настраиваемых аргументов событий для всех моих событий, даже если аргументы события пустые. Но мне было интересно, если другие подумают, что для пользователя было бы яснее, чтобы аргументы события были пустыми, было бы лучше?

Большое спасибо заранее,

Mike

Ответ 1

От Руководства по дизайну каркасов от Брэда Абрамса и Кшиштофа Квалины:

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

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

Лично я думаю, что это сводится к проблеме совместимости. Если вы делаете библиотеку классов потребляемой другими, тогда я буду использовать подкласс. Если вы используете только события в своем собственном коде, то (как сказал Альфред), применяется YAGNI. Это было бы изменением, если вы перейдете от EventArgs к собственному производному классу, но поскольку он только нарушит ваш собственный код, это не слишком большая проблема.

Ответ 2

YAGNI

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

UPDATE:

Как указано adrianbanks, , если, ваш код будет потребляться другим кодом, который не находится под вашим контролем (т.е. код, который вы не можете скомпилировать самостоятельно) или если перекомпилирует потребительский код, то вам следует использовать EventHandler <YourEventArgs> .