イベントの送信者は常に汎用オブジェクトである必要がありますか？

C＃でイベントをプログラミングするときは、次の形式でデリゲートを作成することをお勧めします。

delegate XEventHandler(object sender, XEventArgs e);

私の質問は、デリゲートの最初の引数ですobject sender。常にジェネリックである必要がありobjectますか？タイプの送信者があると、object常に次のようなコードになります。

val = ((ConcreteType)sender).Property;

または、さらに詳細な、

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

強く型付けされた送信者に対する1つの議論は、他のオブジェクトが型を気にすることなくイベントを転送できることです。これはGUI環境では理にかなっているかもしれませんが、GUI以外でもメリットがあるかどうかはわかりません。

送信者のクラスが常に（少なくとも抽象クラスとして）わかっている場合はどうなりますか？私は実装していますたとえば、ListChanged抽象的にイベントをListクラス、および他のクラスは、（例えば、それを継承しようとしている場合はLinkedList、ArrayList）、それはタイプの送信者と私のデリゲートを定義するために、すべての権利でありますかList？

delegate ListChangedEventHander(List sender, ListChangedEventArgs e);

または、従来型object senderをより具体的なタイプに変更することの欠点はありますか？

この時点では、ほとんどが（かなり強力な）規則です。つまり、その規則に従わないライブラリを作成すると、奇妙なことになります。

イベントデザイン・ガイドラインは言います：

DOを使用するobjectイベントハンドラの最初のパラメータの型として、そしてそれを呼び出しますsender。

ただし、現在のガイダンスでは、イベントに独自のカスタムデリゲートを定義するのではEventHandler<T>なく、可能であれば代わりに使用するように指示されていることに注意してください。

設計に関しては、イベントの元の設計者が元々予見していなかった状況でも、イベントハンドラーの再利用を促進すると思います。

推奨の理由は、既存のコード、特にパブリックインターフェイスの変更を必ずしも必要としない将来の変更を可能にするためです。

イベントメカニズム自体は引き続き「VB6」スタイルのイベントに使用できますが、シグネチャを変更する必要がある場合は、既存のすべてのコンシューマーを変更する必要があります（さらに悪いことに、同じイベントの新しいバージョンを作成します）。推奨されるアプローチを使用すると、新しいアイテムが既存のアイテムを継承する限り、既存のコードを修正せずに署名を更新できます。