parameters として受け取るイベントを宣言する必要があることが知られています(object sender, EventArgs args)。なんで？
ripper234
質問する
18236 次
10 に答える
22
これにより、消費者の開発者は、送信者やイベントに関係なく、複数のイベントに対して単一のイベントハンドラーを作成できます。
編集：なぜあなたは別のパターンが必要なのですか？EventArgsを継承して任意の量のデータを提供できます。パターンを変更すると、この新しいパターンを消費することを余儀なくされた開発者を混乱させ、イライラさせるだけです。
于 2008-09-19T19:16:27.913 に答える
11
実際、これがイベントを行うためのベストプラクティスの方法であるかどうかについては議論の余地があります。イベントはコードの2つのセグメントを分離することを目的としているため、イベントハンドラーが送信者を取得し、それを使用して何かを行うために送信者をキャストするタイプを認識しなければならないという考え方があります。パターン。
于 2008-09-19T19:40:47.760 に答える
6
言語に関係なく、あらゆるコールバックメカニズムに適したパターンだからです。誰がイベントを送信したか（送信者）、およびイベントに関連するデータ（EventArgs）を知りたいとします。
于 2008-09-19T19:18:48.390 に答える
5
イベントによって渡されるデータに単一のパラメーターEventArgsを使用すると、既存のコンシューマーを壊すことなく、ソフトウェアの将来のバージョンでイベントにデータを追加できます。既存のEventArgs派生クラスに新しいメンバーを追加するか、新しいメンバーを使用して派生クラスを作成するだけです。
それ以外の場合、一貫性と驚き最小の原則は、データの受け渡しにEventArgsを使用することを正当化します。
送信者に関しては、場合によっては（すべてではありませんが）、どのタイプがイベントを送信したかを知っておくと便利です。送信者引数にオブジェクト以外のタイプを使用することは制限が厳しすぎます。つまり、他の送信者が同じイベント署名を再利用できないことを意味します。
于 2008-09-19T20:04:45.957 に答える
2
使用するのは良いパターンです。そうすれば、イベントを実装するものは何でも、それを送信していたものを見つけることができます。
また、EventArgsをオーバーライドしてデータを渡すのが、最良の方法です。EventArgsは基本クラスです。イベントを呼び出すさまざまなコントロールを見ると、それらはEventArgsをオーバーライドしており、イベントに関する詳細情報を提供します。
イベントを実行するために引数が必要ない場合でも、フレームワークの最初の実行に引数を含めず、後で追加したい場合は、以前のすべての実装を壊して、それらを書き直す必要があります。さらに、フレームワークを作成して配布しようとすると、フレームワークを使用するすべての人がリファクタリングする必要があるため、状況はさらに悪化します。
于 2008-09-19T19:22:28.197 に答える
2
Chris Anderson は、Framework Design Guidelines ブックで次のように述べています。
[T]これは単なるパターンです。イベント引数をクラスにパッケージ化することで、バージョン管理のセマンティクスが向上します。共通のパターンを持つことで、
(sender, e)すべてのイベントのシグネチャとして簡単に学習できます。
このパターンからの逸脱を必要とする相互運用性が主に関係する状況があります。
于 2008-09-19T20:49:34.990 に答える
1
これは、時間の経過とともにイベントモデルを進化させるMicrosoftの方法のようでした。また、「新しい」アクションデリゲートとそのバリエーションを使用して別の方法でそれを行うことも許可しているようです。
于 2008-09-19T19:20:24.643 に答える
0
「オブジェクト送信者」を使用すると、ハンドラー メソッドがイベントを発生させたオブジェクトで何かを行うことになっている場合に、複数のオブジェクトに対して 1 つのメソッドを再利用できます。
EventArgs の主な利点は、この種のイベントにサブスクライブされているすべてのプロジェクトのすべてのハンドラーのシグネチャを変更する必要なく、イベント情報をリファクタリングできることです。
イベントを処理するよりスマートな方法は考えられません。
于 2011-07-05T08:34:22.350 に答える
0
場合によっては、すべてのイベント コンシューマに特定のイベント パラメータを強制的に使用させたい場合があります。たとえば、ブール値パラメータを渡すセキュリティ イベントで、良い場合は true、悪い場合は false です。この場合、消費者に新しいパラメーターを痛感させたい、つまり、消費者をそのパラメーターと結合させたいとします。コンシューマはイベント発火クラスから切り離されていますが、イベントから切り離されていないことに注意してください。
このシナリオは多数のケースに当てはまると思われ、そのようなケースでは EventArgs の値が大幅に減少します。
于 2009-11-02T03:05:45.423 に答える
-1
EventArgsクラスだけでは、コンテンツをインスタンス化するために派生する必要があるため、役に立ちません。これは、サブクラスを使用する必要があることを示しており、多くは .NET に既に存在します。悲しいことに、私は良い一般的なものを見つけることができません.
ロギングを一般的なイベントに委譲したいとしましょう...独自の EventArgs サブクラスを記述せずに。無意味な作業に思えるかもしれませんが、私は既存の機能を使用するのが好きです。Object 引数を介して文字列を渡すことができますが、それは意図した用途に反します。Google で EventArgs サブクラスの適切なリファレンスを見つけてみてください。（少なくとも私はそうしました。）
「EventArgs」と入力すると、文字列「EventArgs」を含むすべてのクラス (using/imports スコープ内) のリストが表示されるため、ReSharper は少し役立ちます。リストを熟読すると、文字列メンバーを持たない多くのクラスが表示されます。ControlEventArgsに到達すると、Text プロパティが使用されている可能性があることがわかりますが、ウィンドウ コントロールのすべてのオーバーヘッドが伴います。 ConvertEventArgsは、データと一緒に型を渡すので便利かもしれませんが、十分に文書化されておらず、本質的に型安全でもない密結合が必要です。 DataReceivedEventArgsには実装がありません。 EntryWrittenEventArgsには、データのバイト配列または StreamingContext を持つ EventLogEntry が必要です。 ErrorEventArgsすべてのログ イベント Exception ErrorEvents を内部的に呼び出してもかまわない場合は、Exception メッセージを使用してより近い方法を使用できます。 FileSystemEventArgsはおそらくこれまでで最も近いもので、2 つの文字列と必要な WatcherChangeTypes 列挙型引数があり、何をしているのかわかっている場合は 0 に設定できます。 Windows.Forms 名前空間が必要な場合でも、 LabelEditEventArgsは int と文字列を使用します。RenamedEventArgsは、追加の文字列を持つ FileSystemEventArgs に似ています。最後に、 System.Runtime.InteropServices のResolveEventArgsは単一の文字列を渡します。他にもライブラリがありますが、私は最も一般的なライブラリのいくつかにこだわりました。したがって、実装によってはErrorEventArgsを使用できます。ロギング用のFileSystemEventArgsまたはResolveEventArgs。
于 2011-03-14T18:15:20.957 に答える