組み込み型の一般的なEventArgs

Question

ポスターのAre EventArg classes needed now that we have genericsとDoes .NET have a built-in EventArgs<T>?は、一般的なEventArgsに対してアドバイスをしています。少なくとも、それは私の気持ちです。

ビルドインタイプの1つが必要なときに使用することは正当なものですか？私の特定のケースでは、私はTCP経由でストリームから読んでいます。データが受信されると、加入者に通知されます。

public event EventHandler<EventArgs<string>> data_received = delegate { }; 

... 

while (!reader.EndOfStream) 
{ 
    if ((data = reader.ReadLine()) != "") 
    { 
     this.data_received(this, new EventArgs<string>(data)); 
    } 
} 

おそらく、イベントはサブスクライバにデータを渡す最善の方法ではありませんか？

Answer 1

短い回答：それは依存しています。

EventArgs<T>クラスはTuple<T>のように、メソッドとの間でデータの受け渡しとデータの受け渡しを行うことができます。いくつかの単純なケースでは、内部使用のためにはTuple<T>が適切ですが、より複雑なケースや一般公開の場合は、別のタイプを使用する方が適切です。

EventArgs<T>には、多かれ少なかれ同じジレンマがあります。内部使用ではこの型を使用するのがOKですが、公開APIでは保守の悪夢につながる可能性があります。

具体的にはEventArgs<T>を一見すると問題はありませんが、後でEndPointのような追加情報を追加する場合はどうしたらいいですか？この場合、EventArgs<T, U>（Tuple<T, U>など）を使用するか、カスタムEventArgsクラスに切り替えることができます。どちらのケースでも、すべてのクライアントを壊してしまいます。このコードのクライアントが1人だけであればOKですが、そうでない場合は...

ボトムラインは内部オブジェクト用ですが、EventArgsを使用しても構いませんが、カスタムイベント引数を使用することを推奨します。

P.S.イベントの一般的な命名規則はCamelCaseです。具体的には、DataReceivedがイベントのより適切な名前であることを意味します。