Являются ли обратные вызовы событий с параметрами (object, EventArgs) пережитком 1.1 и WinForms? - PullRequest
2 голосов
/ 13 декабря 2008

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

void Callback(object sender, EventArgs args) { ...}

и должен быть прикреплен с

MyObject.Event += new EventHandler(Callback);

Теперь все было хорошо в те времена .Net 1.1, но начиная с 3.5 я обнаружил, что гораздо проще и интуитивно проще просто вызывать событие типа Action или один из его обобщений и писать метод точно так же, как если бы он вызывался явно; ни один из этих отправителей объекта или EventHandler Cruft.

В сущности, я считаю, что это категорический императив дизайна. Если вы разрабатываете метод по-другому для обратного вызова события, это означает, что метод, по крайней мере, неявно имеет некоторую информацию о его вызове - это главное нет-нет!

Я полностью готов принять то, что я что-то упускаю. Что вы, ребята, думаете по этому поводу, FxCop не прав или я?

Ответы [ 2 ]

1 голос
/ 13 декабря 2008

Вы должны следовать соглашению.

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

    MyObject.SomeEvent + = новый EventHandler (SomeMethod);

  2. Метод обработчика события должен возвращать void (не имеет смысла возвращать что-либо обработчику события), и следует придерживаться соглашения о получении объекта отправителя с данными в аргументах события.

Причины "дерьма" (отправитель и eventargs)

  • Конвенция
  • Расширяемость легче реализовать (как класс, который вызывает событие, так и класс, который его обрабатывает)
  • Иногда вы хотите знать, кто послал событие.
  • Любые / все данные могут быть инкапсулированы в аргументы события.
  • Вы можете использовать один и тот же обработчик событий для многих событий.

Картина продолжается дальше. Вы также должны вызвать ваше событие SomeEvent в защищенном методе с именем OnSomeEvent (), чтобы производные вашего класса могли делать такие вещи, как подавление событий, вызывать их потокобезопасным способом, поднимать их в потоке пользовательского интерфейса, поднимать их с тайм-аутами или защита от исключений, процессы регистрации событий и т. д.

Эй, это не идеальный шаблон (возможно, отправитель мог быть помещен в аргументы события), но почти весь код .Net следует за ним, а код фреймворка всегда следует за ним. Почему бы и не следовать?

0 голосов
/ 13 декабря 2008

Я не думаю, что FxCop обновлялся достаточно долго; Вы пробовали это с инструментами анализа кода VS2008 (преемник FxCop)?

...