Почему события в C # должны принимать (отправитель, EventArgs)?

37
задан Sam 3 July 2013 в 13:19
поделиться

8 ответов

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

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

22
ответ дан Greg Hurlman 3 July 2013 в 13:19
поделиться
  • 1
    Спасибо за ответ. Заметьте, что с флагом constant_tsc, rdtsc действительно обновляет однородно; посмотрите кавычку, которую я добавил к своему вопросу. SO_TIMESTAMP в msec точности, в то время как rdtsc в точности национальной безопасности, и это - точность, в которой я нуждаюсь. Мне не интересно во время, пакет прибыл в ядро, но во время пользователь получил его, так как это - часть, которую ускоряет мое приложение. – avner 3 August 2010 в 07:26

Поскольку это - хороший шаблон для любого механизма обратного вызова, независимо от языка. Вы хотите знать, кто отправил событие (отправитель) и данные, которые являются подходящими для события (EventArgs).

6
ответ дан Eric Z Beard 3 July 2013 в 13:19
поделиться
  • 1
    В то время как эта ссылка может ответить на вопрос, лучше включать основные части ответа здесь и предоставить ссылку для ссылки. Ответы только для ссылки могут стать недопустимыми, если связанная страница изменяется. – Matthew Green 19 February 2014 в 22:30

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

Также переопределение EventArgs и передающих данных через них является лучшим методом. EventArgs являются базовым классом. Если Вы смотрите на различные средства управления, что события вызова, они переопределили EventArgs, который дает Вам больше информации о событии.

, Даже если Вам не нужны аргументы, чтобы сделать событие, если Вы не включаете их с первым показом платформы и хотите добавить их позже, Вы повреждаете все предыдущие реализации и имеете для переписывания их. Плюс то, если Вы создание платформы и попытка распределить это это становится хуже, потому что все, которые используют Вашу платформу, должны будут осуществить рефакторинг.

2
ответ дан David Basarab 3 July 2013 в 13:19
поделиться
  • 1
    Мой вопрос был о rdtsc, потому что мне нужно высокое разрешение и низко наверху. Я только хочу удостовериться его надежность через ядра, так как я couldn' t находят документацию об этом. Хотя, мое чувство хорошо. Около, для использования таймера высокого разрешения (вероятно, CLOCK_MONOTONIC_HR), I' ll должен перекомпилировать ядро. Это не опция, так как я can' t требуют этого от всех моих клиентов. – avner 6 September 2010 в 09:04

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

1
ответ дан casademora 3 July 2013 в 13:19
поделиться
  • 1
    1) рев является 1-ми 5 строками, которые производятся Вашим кодом (Вы видите, что национальная безопасность всегда 246), 279595 629885246 279596 630958246 279597 631777246 279598, 633 596 246 2) Дополнительными проблемами с clock_gettime являются свои издержки. Согласно моему statiscs (взятие показывают 1001 раз неоднократно безо сна), среднее число наверху clock_gettime (CLOCK_MONOTONIC, & ts), 281 национальная безопасность на сильной nehalem машине; в то время как взятие rdtsc использует только 8 национальной безопасности на той же машине. – avner 2 September 2010 в 13:14

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

11
ответ дан Jeff Bridgman 3 July 2013 в 13:19
поделиться
  • 1
    @MatthewGreen я развернул свой ответ с некоторыми результатами моего собственного исследования. Я оставил предыдущий URL, потому что это может все еще быть полезно и вряд ли станет недопустимым. – Will 4 April 2014 в 18:05

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

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

Что касается отправителя, в некоторых (но не все) случаи полезно знать то, что тип отправил событию. Используя тип кроме объекта для отправителя аргумент слишком строг: это означало бы, что другие отправители не могли снова использовать ту же подпись события.

4
ответ дан Joe 3 July 2013 в 13:19
поделиться
  • 1
    Я уже установил привязку CPU:) Моим вопросом являются приблизительно 2 потока на 2 различных ядрах процессора. Мой поток recv опрашивает NIC относительно пакетов без контекстных переключений и незамедлительно относительно отправки исходящих пакетов. В моей среде микросекунды рассчитывают много! – avner 3 October 2010 в 13:05

Chris Anderson говорит в книге Руководства по проектированию Платформы:

[T] его примерно шаблон. Путем упаковки аргументов события в классе Вы получаете лучшую семантику управления версиями. При наличии общего шаблона (sender, e) это легко изучено как подпись для всех событий.

существуют ситуации, главным образом включающие interop, который потребовал бы отклонения от этого шаблона.

2
ответ дан fryguybob 3 July 2013 в 13:19
поделиться
  • 1
    HEPT звучит плохим для моих потребностей - см. мой предыдущий комментарий о HEPT. RDTSC выглядит большим и надежным в hunders тестов, которые я сделал в нескольких, удаляют сердцевину среды (даже для машин, которые возросли в течение многих недель). Кроме того, прочитайте цитату о " TSC как настенные часы timer" в моем запросе. Нижняя строка, я только ищу официальное одобрение. Практически, RDTSC, действительно кажется, делает работу. – avner 19 October 2010 в 13:55

Иногда вам нужно заставить всех ваших потребителей событий использовать определенный параметр события, например, событие безопасности, которое передает логический параметр, истинно для хорошего, ложно для плохого. В этом случае вы хотите, чтобы ваш потребитель был болезненно осведомлен о новом параметре, т.е. вы хотите, чтобы ваши потребители были связаны с этим параметром. Обратите внимание, ваши потребители по-прежнему отделены от вашего класса активации события, но не от вашего события.

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

0
ответ дан 27 November 2019 в 04:53
поделиться
Другие вопросы по тегам:

Похожие вопросы: