Должен ли я использовать EventArgs или простой тип данных?

Question

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

Например, в моей библиотеке у меня есть что-то вроде этого:

public delegate void LostConnectionEventHandler(string address);
public delegate void MessageReceieved(byte[] bytes);

Какая стандартная практика для этого? Должен ли я заменить string address на ConnectionEventArgs и byte[] bytes на MessageEventArgs?

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

Спасибо!

Answer 1

Рекомендации .NET Framework указывают, что тип делегата, используемый для событие должно принимать два параметра, параметр «источник объекта» с указанием источника события и параметра «е», который инкапсулирует любую дополнительную информацию о событии. Тип параметр "e" должен быть производным от класса EventArgs. Для событий которые не используют никакой дополнительной информации, .NET Framework имеет уже определен соответствующий тип делегата: EventHandler.

Ссылка: http://msdn.microsoft.com/en-us/library/aa645739(v=vs.71).aspx

Другая полезная информация: http://msdn.microsoft.com/en-us/library/ms229011.aspx

Answer 2

Лично мне нравится идея получения от EventArgs,

если вам нужно передать информацию о состоянии и объединить объекты, вы можете легко это сделать, см.

MouseEventArgs типа, например.

используя подход ООП, если у вас есть событие / конструкция, которая принимает объект типа EventArgs, вы можете положиться на тот факт, что каждый производный от него объект будет работать таким же образом, в то время как у вас есть объект другого типа, который не разделяет один и тот же базовый класс, вы можете со временем что-то сломать.

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

Answer 3

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

Answer 4

Нет необходимости выводить из EventArgs, однако соглашение следует общему правилу ( Ввести объект параметра ) рефакторинга. И обоснование этого правила хорошо задокументировано.

Answer 5

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