Чи повинен відправник події завжди бути загальним Об’єктом?

При програмуванні подій на C # рекомендується створити делегата у вигляді:

delegate XEventHandler(object sender, XEventArgs e);

Моє питання на перший аргумент делегата object sender. Чи завжди це має бути родовим object? Наявність відправника типу objectзавжди призводить до коду, подібного до цього.

val = ((ConcreteType)sender).Property;

або, ще більш багатослівний,

ConcreteType obj = sender as ConcreteType
if (obj != null) { ... }

Один з аргументів проти сильно набраних відправників - це те, що інші об'єкти можуть пересилати подію, не переживаючи про тип. Хоча це може мати сенс у середовищі графічного інтерфейсу, я не впевнений, чи може це отримати користь поза графічним інтерфейсом.

Що робити, якщо клас відправника завжди відомий (принаймні як абстрактний клас)? Наприклад, якщо я реалізую ListChangedподію в абстрактному Listкласі, і якщо інші класи збираються успадкувати його (наприклад LinkedList, ArrayList), чи все в порядку визначити мого делегата із типом відправника List?

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

Або, чи не буде змінити звичайний object senderна більш конкретний тип?

На даний момент це здебільшого (досить сильна) конвенція. Тобто, це буде дивно, якщо ви напишете бібліотеку, яка не відповідає цій конвенції.

Правила дизайну подій кажуть:

DO використовувати objectяк тип першого параметра обробника подій, і викликати його sender.

Однак ви можете зауважити, що поточні вказівки говорять, що ви не повинні визначати власний спеціальний делегат для подій, а використовувати EventHandler<T>натомість, якщо можете.

Що стосується дизайну, я б здогадався, що він також сприяє повторному використанню обробників подій, навіть у контекстах, які спочатку не передбачалося оригінальним дизайнером події.

Причина рекомендації полягає в тому, що вона дозволяє проводити майбутні зміни, які не обов'язково потребують змін до існуючого коду, і особливо публічного інтерфейсу.

Сам механізм подій все ще може використовуватися для подій у стилі "VB6", але вам доведеться змінити всіх існуючих споживачів, якщо вам коли-небудь потрібно змінити підпис (або ще гірше: створити нові версії тих же подій). За допомогою рекомендованого підходу, поки нові елементи успадковуються від існуючих, ви можете оновити підпис, не виправляючи існуючий код.