4

重複の可能性：
C＃のイベント（送信者、EventArgs）を取得する必要があるのはなぜですか？

プロジェクトでVS2012コード分析ツールを実行したところ、このスニペットについて文句を言うことがわかりました。

public delegate void PerMbHandler(long totalMb);

public event PerMbHandler NotifyMegabyteIncrement;

CA1009「MyWebClient.PerMbHandler」の2番目のパラメーターをEventArgs、または「e」という名前のEventArgsを拡張するタイプのインスタンスとして宣言します。

MSDNの説明：

イベントハンドラーメソッドは2つのパラメーターを取ります。1つ目はSystem.Object型で、「sender」という名前です。これは、イベントを発生させたオブジェクトです。2番目のパラメーターのタイプはSystem.EventArgsで、名前は「e」です。これは、イベントに関連付けられているデータです。たとえば、ファイルが開かれるたびにイベントが発生した場合、通常、イベントデータにはファイルの名前が含まれます。

MSDNは、規則が存在する理由ではなく、規則が何であるかを単純に述べています。

EventArgsのサブクラスではなく、長いパラメーターを使用すると何がうまくいかない可能性がありますか？それは慣習とプログラマーの期待の問題ですか、それともパターンに従わなければならない微妙な技術的理由がありますか？コードは正常に機能しているように見えるので、微妙に言います。

4

2 に答える 2

5

EventArgsのサブクラスではなく、長いパラメーターを使用すると何がうまくいかない可能性がありますか？

イベント引数
それ自体は間違っていませんが、拡張可能ではありません。議論のために、おそらく6か月以内に、2つのロングを渡すか、文字列を追加するか、情報のリスト全体を追加する必要があります。署名を使用EventArgsすると、任意の派生型を渡すことができ、既存のコンシューマーを壊すことはありません。特定の値のタイプでは、非常に制限されます。

EventArgsを使用すると、イベントを発生させたクラスと通信することもできますCancelEventArgs。

送信者
正直なところ、私は送信者を何かに使用することはめったにありません。また、多少あいまいな場合もあります。たとえば、テキストボックスへの入力によってトリガーされるコントロールのカスタムイベント...送信者は誰ですか？テキストボックス（おそらくもっと便利です）、またはカスタムイベントを宣言するコントロール？

それでも、これはおなじみの規則であり、十分に文書化されたインターフェースを使用すると便利です。

于 2012-10-26T19:13:28.967 に答える
2

何も問題はありません。イベントとイベントハンドラのシグネチャは強く型チェックされます。メッセージが行うのは、スピードバンプについて警告することだけです。これにより、イベントを使用する別のプログラマーに、イベントにそのような異常な署名がある理由に戸惑うことになります。スピードバンプはバグを生みます。たとえば、プログラマーが送信者を取得する必要があると主張するようなバグです。

FxCop（別名「コード分析」）が何をしようとしているのかを覚えておいてください。エラーをチェックしません。それがコンパイラの仕事です。それはあなたが考えていなかったかもしれないことについてあなたに知らせるためにそこにあります。そのため、特にCASについてヌードルしたり、悪名高いCA2000に不適切なフラグを立てたりする場合は、少し厄介になることがあります。しかし、これは確かに良い警告です、あなたはそれについて考えていませんでした。

于 2012-10-26T19:28:49.037 に答える