Событие, которое не имеет аргументов, должно определять свои собственные EventArgs или просто использовать System.EventArgs? - PullRequest
12 голосов
/ 23 августа 2009

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

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

EventHandler<System.EventArgs> MyCustomEvent;

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

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

public class MyCustomEventArgs : EventArgs
{
}

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

EventHandler<MyCustomEventArgs> MyCustomEvent;

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

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

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

Mike

Ответы [ 2 ]

14 голосов
/ 23 августа 2009

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

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

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

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

9 голосов
/ 23 августа 2009

YAGNI

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


UPDATE:

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...