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

Ответ 1

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

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

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

Ответ 5

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

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

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

Ответ 6

Крис Андерсон говорит в книге "Руководства по дизайну рамок":

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

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

Ответ 7

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

Ответ 8

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

Я не могу придумать более разумный способ борьбы с событиями.

Ответ 9

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

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

Ответ 10

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

Предположим, вы хотите делегировать ведение журнала для общего события... БЕЗ ПИСЬМО СОБСТВЕННОГО EventArgs SUBCLASS. Это может показаться бессмысленным упражнением, но мне нравится использовать существующие функции. Вы можете передать свою строку через аргумент Object, но это противоречит ее предполагаемому использованию. Попытайтесь найти хорошую ссылку подклассов EventArgs в Google, и вы сойдете с ума. (По крайней мере, я это сделал.)

ReSharper помогает немного, так как при вводе "EventArgs" вы увидите список всех классов (в пределах области использования/импорта), которые СОДЕРЖАЮТ строку "EventArgs". Просматривая список, вы увидите много классов без членов строки. Когда вы дойдете до ControlEventArgs, вы увидите, что свойство Text может использоваться, но со всеми издержками управления Windows. ConvertEventArgs может оказаться полезным, так как вы передаете тип вместе с данными, но это все еще требует жесткой связи, которая ни хорошо не документирована, ни неотъемлемо безопасна по типу. DataReceivedEventArgs не имеет реализации. EntryWrittenEventArgs требуется EventLogEntry с байтовым массивом или StreamingContext для данных. ErrorEventArgs ближе, с сообщением об исключении, если вы не возражаете при вызове всех событий журнала Exception ErrorEvents внутренне. FileSystemEventArgs, вероятно, самый близкий, с двумя строками и требуемым аргументом enum WatcherChangeTypes, который может быть установлен в 0, если вы знаете, что делаете. LabelEditEventArgs использует int и строку, если вы не против использования пространства имен Windows.Forms. RenamedEventArgs похож на FileSystemEventArgs с дополнительной строкой. Наконец, ResolveEventArgs в System.Runtime.InteropServices передает одну строку. Существуют и другие библиотеки, но я придерживался некоторых из наиболее распространенных. Таким образом, в зависимости от реализации я могу использовать ErrorEventArgs, FileSystemEventArgs или ResolveEventArgs для ведения журнала.