3

Ted Faison は、イベントベースのソフトウェア設計に関するポッドキャストで、.NET、C++、および Java のイベント ステートメントの "sender" オブジェクトと "self" オブジェクトについて次のように言及しました。

private void Button_Click(object sender, RoutedEventArgs e)

たとえば、上記の例では、「送信者」は実際にはイベントを生成したオブジェクトではなくプロキシであるため、アプリケーションをそれほど緊密に結合したくないため、誤称です。

私は彼を間違って理解しましたか (デバッグすると、「送信者」は実際には元のオブジェクトのように見えます)。

それとも、これらの言語の一般的なイベント パターン (例: 一般的なクリック ハンドラー) は密接に結合されていますが、複合アプリケーションなどでは、より分離する必要があります。

彼はまた、たとえば EventArgs から継承を行うべきではないと述べました。これは、イベントごとに 1 つのクラスが爆発的に増加し、いくつかの変数しか転送されないためです。彼の意見では、多くの場合、たとえば文字列を送信するだけで済みます。彼は、この意見は Microsoft Patterns and Practices が示唆するものとは反対であると述べました。

これらの分野について何か考えはありますか？

4

2 に答える 2

1

まず、「送信者」はクリックしたボタンへの参照を保持します。複数のボタンがすべて同じイベントにフックされている場合、これは、どのボタンを押したかを確認する方法です（これを読み取るためにイベント引数に何かを渡していない場合）。

また、frmo EventArgsを継承する新しいeventargsを作成すると、クラスが爆発的に増加する可能性があることにある程度同意します。したがって、causionで使用してください。EventArgs.Emptyを発生させてから、イベントをキャッチするコードで、データのイベントを発生させたオブジェクトを明示的にクエリするのが好きです。つまり、イベントをキャッチすると、イベント引数からデータを読み取る代わりに、イベントを発生させたオブジェクトに移動し、関心のあるプロパティのデータを読み取ります。これにより、必要なものだけを簡単に読み取ることができます。 、しかしもちろん-発生したイベントとプロパティの読み取りの間にこれらのプロパティが変更された状況に陥る可能性があります。

于 2009-03-18T22:57:33.483 に答える
1

ほとんどの場合、イベントを発生させたのはsender （Buttonまたは何でも）です。これが当てはまらない場合があります-（おそらく怠惰な）パススルーイベントなど：

class Foo {
   private Bar bar;
   public Foo(Bar bar) {
       this.bar = bar;
   }
   public event EventHandler SomeEvent {
       add {bar.SomeEvent += value;}
       remove {bar.SomeEvent -= value;}
   }
   //...
}

ここで、foo.SomeEventをサブスクライブすると、Barインスタンスによって発生したイベントが実際に返されます。したがって、返されsender ませんfoo。しかし、これは間違いなく、実装Foo.SomeEventが正しくないためです。

正直なところ、ほとんどの場合、チェックする必要はありませんsender。これが役立つ主な場合は、多数のコントロールがハンドラーを共有する場合です。通常、送信者はサブスクライブしたインスタンスであると想定できるはずです（参照の同等性テストの目的で）。

Re-EventArgs標準パターン（新しいイベントタイプを作成する場合）は、これから継承することをお勧めします。これから逸脱することはお勧めしません。マイナーな理由は、を使用できることですがEventHandler<T>、他の差異の理由もあります。その上、他の人が期待することをすることは十分な理由である場合があります。人々は派生した価値を期待しています。EventArgs

そうは言っても、私は以前に（MiscUtilのPush LINQで）非標準のイベントを実行しましたが、これはすでに非常に珍しい設定であったため、違和感はありませんでした。

于 2009-03-18T23:00:26.300 に答える