Является ли плохим тоном использование не EventHandler как типа делегата события?
Часто использую события в коде игры (под Unity3d, если быть точным, но в основном в коде, отвязанном от движка/сцены). После прочтения Рихтера честно использовал EventHandler, но ничего, кроме загромождения кода мне это не принесло. Изменил на Action, стало чище, проблем не заметил.
В CLR via C# использование EventHandler с его костыльным приведением sender'а и заглушкой EventArgs.Empty обосновывалось тем, что это общепринято и не вынуждает плодить делегаты. С первым не поспоришь, но второе уже много лет как неактуально в связи с введением generic делегатов, в т.ч. и встроенных Action. При необходимости первым аргументом можно поставить типизированный sender (что явно чище, чем Object sender), а если нужно что-то передать, то вторым аргументом будет либо один аргумент передаваемого типа, если нужно передать экземпляр одного типа, либо данные, упакованные в наследника EventArgs, если их много.
Меньше boilerplate кода, типобезопасность. Что я делаю не так?
Конечно, имеется ввиду использование во внутренней логике приложения, не зависящей от каких-нибудь сотен событий из WinForms/WPF/etc.
P.S. удивлен, что этот довольно распространенный вопрос задавался на большом количестве англоязычных, но его нет на тостере) Интересно мнение местной аудитории.
Возможно вы немного удивитесь, но использовать события вообще не желательно=)
Поскольку очень легко забыть отписатся от события, а это необходимо чтобы не было утечки. А если вы и не забыли, то очень часто нужны будуть костыли в виде кеширования объекта к которому подписались для дальнейшей отписки... Плюс проблемы с лямбдами. Я стараюсь заменять их на IObservable из Reactive Extensions for .Net.
Уже не первый раз слышу хорошие отзывы об этой библиотеке, видимо стоит ее изучить)
Но все же и обычными нужно уметь пользоваться при необходимости, т.ч. все же интересно, почему все используют EventHandler там, где проще и чище будет с Action.
Таков паттерн, договоренность между программистами, чтобы разграничить ответственность и дать понять другим программистам что этот класс предназначен для передачи данных в событиях и не нужно его пытаться использовать где-то еще. Если вы не будете использовать EventHandler, то ничего ужасного не случиться, но те кто знают про этот паттерн могут сконфузиться и начать искать причину почему здесь не EventHandler. Такая же история из интерфейсами, вас никто не заставляет писать IService, можно просто Service.
Вся эта затея с событиями началась со Smalltalk-а, там не было методов, только события и sender был нужен для обратного ответа. При работе с UI его можно использовать для изменения состояния sender и вам будет не важно сколько у вас элементов, достаточно всего одного обработчика для всех
Я в общем-то и не спорю с тем, что это общепринято и что sender полезен. Я о том, что EventHandler появился еще до generic делегатов, поэтому Object в качестве типа sender был оправдан. Но в современных версиях .NET в таком приеме уже и смысла нет. Одну проблему даже решили - добавили EventHandler, чтобы не приводить к наследнику EventArgs, но этого же мало. Хотя и исправить сложившийся порядок уже нельзя.
Впрочем, это, видимо, скорее дело вкуса/кодстайла, я больше опасался каких-то скрытых технических подводных камней, но вроде как их и нет, спасибо за ответы.
А я его толком и не видел, т.к. ни в чем серьезном пока не участвовал) Буду копать современные подходы, я то думал, что какой-нибудь WPF с его сотнями событий это современно (хотя какой-нибудь INotifyPropertyChanged с его строковыми свойствами положительных мыслей о прогрессе не вызывает...).
Средний
Простой