イベントを宣言する好ましい方法

.NETイベントモデルの理解にかなり満足しています。システムの小さなニュアンスを誤解しているのではないかと思います。

クラスにイベントを入れ始めたとき、次のような標準的な方法を使用します。

public event EventHandler<MyEventArgs> MyEvent;

これは、イベントにサブスクライブするものには、次のようなメソッドが必要であることを意味しました。

void HandleThatEvent(object sender, MyEventArgs args){...}

これは素晴らしいことですが、送信者を気にすることはめったにないため、多くのメソッドシグネチャが肥大化しました。

だから私は自分のデリゲート型の宣言に切り替えました

public delegate void MyEventHandler(SomeClass argument);

これにより混乱が減りましたが、ハンドラーの作成に関して小さな問題が残りました。

eventImplmentor.MyEvent += HandleThatEvent;
.
.
.
void HandleThatEvent(/*oh, um, what arguments does it take? Intellisense isn't telling me*/)

だから私はデリゲートの宣言に戻って見て、そして戻ってそれらを書くか、それをコンパイルして言われるのを待たなければなりません。

だから今、代わりに、私はちょうどAction、Action<T>または適合するテンプレートを使用しています。

public event Action<SomeClass> MyEvent;

イベントにカーソルを合わせて、どのパラメーターが期待されるかを知ることができます。

私の質問、結局のところ：C＃でイベントを宣言するためのベストプラクティスはありますか？EventHandler<T>道に戻る必要がありAction<T>ますか、それとも容認できますか？

単純な内部イベント処理には、提案しているように単にActionまたはを使用するものがありAction<T>ます。内部イベントでも、Senderを含む標準パターンを使用する傾向があります。これは、後でクラスまたはイベントを公開するタイミングがわからないため、イベントメソッドをリファクタリングするだけで済むというペナルティはないからですそれは公開。

イベント処理のシグネチャは単純なシナリオの場合よりも少し重いですが、追加のイベント引数が時間とともに必要になる可能性があるため、増分移行を処理するように設計されていることに同意します。全体として、特にお気付きのとおり、適切なIntelliSenseサポートを取得するのはあなただけなので、標準パターンに固執します。

それが価値があるので、私はこれに時間を割いて、別のイベント処理パターンを思いつきました。。ここでの目標は、Senderを削除することではTSenderなく、として弱く型付けするのではなく、一般的に強く型付けするようにすることSystem.Objectでした。とてもうまくいきます。ただし、これを行うとIntelliSenseのサポートが失われるため、残念ながらトレードオフが発生します。

全体として、標準パターンに固執しますが、これを行うための潜在的に優れた方法を考えることは興味深いです。